Every few months someone asks why we use Rails in 2026. Isn't it old? Isn't it slow? Shouldn't you be using [whatever launched on Hacker News this week]?
Rails turned 20 last year. Shopify runs on it. GitHub runs on it. Basecamp runs on it. These are not small, simple apps.
Here's why we keep choosing it for client work:
Speed to ship. Rails conventions mean less decision-making. Authentication, database migrations, background jobs, email, API endpoints — all built in or one gem away. A Rails developer can scaffold a working CRUD app with auth in an afternoon. Try that with a microservices architecture.
One developer can do a lot. For MVP-stage startups, you don't want a team of five specialists. You want one or two generalists who can build the whole thing. Rails is built for that — one person, full stack, shipping features.
It scales further than you think. The "Rails doesn't scale" narrative died years ago. With proper indexing, caching, and background jobs, a single Rails server handles more concurrent users than most MVPs will see in their first year. Optimize when you have the problem, not before.
AI tools write decent Rails. Because Rails has been around so long and has such consistent conventions, AI coding tools generate surprisingly usable Rails code. The conventions act as guardrails — pun intended.
We pair Rails with Flutter for mobile. Rails API backend, Flutter frontend. Two mature, boring, well-documented technologies that ship fast and don't surprise us at 2am. That's the stack you want when you're spending someone else's money.
