Is Rails still a safe bet for a new SaaS?

Yes, though not for the reason people usually give. Ruby on Rails is a smaller share of the programming world every year. That's true, it isn't close, and I'm not going to argue with it. What that number doesn't tell you is anything about support: the training data, the engineers who can take it over, the hosting, the twenty years of problems somebody already solved. Support is what you're actually buying when you pick a stack for something you intend to still own in three years. Share and support are different measurements. Rails is losing the first one and sitting near the top of the second.

Both sides of that, with the numbers.

The question underneath the question

Nobody with a business to run actually wants to know whether Rails is good. They want to know whether picking it means getting stuck. That fear breaks into three questions you can check the answers to:

1. Will the AI be any good at writing it?
2. Will I find someone to take it over?
3. Are the boring parts already solved?

1. The AI writes it well, and somebody measured it

In August 2026 the Rails Foundation stopped relying on the community's general impression and paid Evil Martians to test it. Stage one: 21 self-contained tasks on a real Rails application, eight models, 504 runs, $491 of total spend. Best model solved 92 percent. The public leaderboard has since grown to twelve models at 63 runs each, and the top three sit between 90 and 92 percent. One of them gets through an average task on roughly 24,700 tokens, which is to say cheaply.

Fine. But the reason behind that number is more useful than the number, because it runs opposite to what the popularity charts would predict.

What matters to a model isn't how many people are writing Rails this year. It's how much Rails it learned from, and how much of that agrees with itself.

Rails wins the first and dominates the second, and the second is the one nobody counts. Rails has a strong convention for nearly everything: where a file goes, what it's called, how a database change gets written, how a page is served. So twenty years of public Rails code mostly looks the same. A million applications, written by different people across two decades, put the same things in the same places under the same names.

Now picture a framework with a much larger share and no such agreement, where there are six popular ways to fetch data and four live opinions about folder structure, and the fashionable answer moved twice since the model was trained. More code, less consensus. Bigger corpus, weaker signal.

Rails' creator puts it in one line on the framework's own AI page: convention over configuration, he writes, "set the path for 20+ years of great training data." Nobody planned that in 2004. It's a windfall. It's also not the sort of asset a newer framework can decide to go acquire this year.

There's a catch in the same benchmark, and I've written about it elsewhere on this site: models tend to hand-roll their own version of something instead of reaching for the framework's built-in tool, with correct-API recall running between 8 and 35 percent. Closing that gap is exactly what a senior engineer does. It's an argument about how to use AI on Rails, not about whether Rails is a good target for it.

Everything above is about the model's side of the exchange. There's a second half I'll take up separately: whether you can read what the model wrote. Ruby is unusually close to plain English, so a non-programmer really can open a Rails file and follow the gist of it, which is more than most stacks offer an owner. That turns out to be a sharper double edge than it sounds, and it deserves its own piece.

2. There are people who can take it over

The test of a stack isn't how it feels on day one. It's what happens the first time you need somebody who wasn't there when it got built. And you will need that, probably in a hurry.

Rails passes for a structural reason. Because Rails applications look alike, a developer who has never seen your code can open it and find things. Onboarding instead of archaeology. That's the whole mechanism behind a clean handoff.

You can locate the people by looking at who runs Rails at scale. GitHub operates a roughly two-million-line Rails codebase with over a thousand engineers shipping about twenty times a day. Shopify's monolith is one of the largest and oldest on earth, 2.8 million lines and half a million commits, under continuous development since 2006; over Black Friday 2025 it carried $14.6 billion in merchant sales, peaking near 489 million requests per minute at the edge. Basecamp, where Rails was born. Kickstarter. Zendesk. Twitch. Airbnb in its formative years. Gumroad runs a global digital-commerce business on Rails with a famously small team.

Two more I know from the inside rather than from a case study: I was an early engineer at Stitch Fix and a senior engineering manager at ezCater. I don't raise them for the logos. Companies like those have been manufacturing senior Rails engineers for fifteen years, and those engineers go on to work somewhere else. That's what a labor market is. It's why a Rails app has plausible handoff partners and operational partners, and why "the person who built it vanished" is a recoverable event instead of a fatal one.

3. The boring parts got solved a long time ago

What kills a young SaaS usually isn't the feature work. It's the operational layer. Backups nobody tested. A background job that fails quietly at 3am. A deploy only one person can perform. A security patch nobody applied.

Rails has had twenty years of production traffic to find those in. There's a security team and a disclosure process. There are managed hosts whose entire product is running Rails properly. Ask almost any operational question and there's a documented, well-worn answer, and better than that, somebody has already hit your exact problem and written down what they did about it.

Ask the same question about a two-year-old stack and sometimes the answer is a GitHub issue from four months ago with no replies. Both stacks can run your app. Only one has a body of accumulated experience about the bad day.

4. The new thing is written down too

The obvious objection: fine for a 2015 SaaS, but I'm building something with AI in it, and surely that's uncharted for a twenty-year-old framework.

Not really. Obie Fernandez, who wrote The Rails Way, spent a year building an actual AI product in Rails and turned it into Patterns of Application Development Using AI: named, reusable patterns for what AI features actually need, with a shipped product behind them instead of a demo. If you're building an AI-powered SaaS, the Rails playbook for that is a book. Not every stack has one.

Now the honest part

Rails is shrinking. The real numbers, unspun.

Measured by share of GitHub users, Ruby has fallen further than any other major language: second place in 2011 at over 18 percent, eleventh today at 3.2 percent. The 2025 Stack Overflow Developer Survey puts it around 6 percent of developers, ranked 16th. Ruby questions on Stack Overflow have declined more or less every year since 2013.

If you want the language with the arrow pointing up, this isn't it, and any shop telling you otherwise is selling.

But read one line further in that same GitHub analysis. Those are percentages of a user base that grew more than twentyfold over the period. Counted as people, there are now more than three times as many active Ruby developers on GitHub than there were in 2011, at the height of the hype, when Rails was the most fashionable thing in software.

That distinction carries the argument, so let me put it flatly:

Share is a ratio. Support is a count. You're buying the count.

Rails' ratio fell because the denominator exploded. The industry added millions of developers, most of them writing JavaScript and Python. The numerator didn't collapse. Meanwhile everything that determines whether you can get help, the volume of public code, the answered questions, the mature libraries, the tested runbooks, the engineers carrying a decade of production scars, only accumulates. Twenty years of solved problems don't un-solve themselves because a newer framework is trending.

A stack can be well past its fashion peak and still be the best-supported option in front of you. For infrastructure that's not an anomaly, it's the normal condition. Postgres, Linux and email are all past their fashion peaks. You'd be ill-advised to avoid any of them on those grounds.

When Rails is the wrong answer

I'd rather say this plainly than have you discover it later. Rails is wrong when:

• Your team already knows something else well. Familiarity beats framework nearly every time. A team shipping confidently in Django or Laravel or Node shouldn't switch because of an article.
• The core of the product is genuinely real-time or high-concurrency. Trading, multiplayer, live streaming at scale. Rails goes further here than its reputation suggests, but this isn't where it's strongest.
• The heart of it is machine learning or data science. Python's home turf, and it isn't close.
• There's barely a server. A mobile-first product with a thin backend doesn't need this much framework.
• You have a front end you like. Keep it. Rails is perfectly happy serving an API behind a React app you already paid for.

The line I won't cross is moving an application to Rails that had no reason to move. Same mistake an AI tool makes when it reaches for the pattern it knows instead of the one the problem needs, just pointed the other way.

What this means for time to market

Time to market gets measured to launch, and launch is the wrong finish line.

The number that decides whether a SaaS survives is time to the second version. The one built after real users showed up and told you what you got wrong, usually on a budget you didn't have at the start, often by somebody other than whoever built version one.

Rails isn't the fastest route to a demo. Lovable is faster to a demo. Rails is among the fastest routes to a version two that a person you haven't met yet can pick up and carry, and that's the only speed that compounds.

That's the bet. It isn't a bet on Rails winning share back; it won't, and it doesn't need to. It's a bet that in three years you can still find somebody who'll open your codebase, understand it, and fix whatever just broke, and that the AI you hand it to will have seen a million applications shaped like yours.

If you want to know whether the app you already have clears that bar, that's what the diagnostic is for.