Why we rebuild in Rails
The stack both machines and humans already know.
Rails is not the fashionable answer in 2026. It is the one that leaves you with something maintainable, which is a different question and the one that costs you money. Here is the argument, with the evidence and the caveats.
The short version
Three reasons, none of them fashion.
Models write it well
Rails is convention over configuration. There is usually one right place for a thing and one right way to do it, and the models have seen that shape a million times. Less invention per feature, less token spend, fewer surprises in the diff. This is no longer a belief; the Rails Foundation measured it.
Humans can take it over
A Rails app follows a shape every Rails developer recognizes. When you hire someone in a year, they open the repo and know where everything lives. Rails talent is senior and not cheap, but it is real, and it is exactly the kind of person you want maintaining the thing that runs your business. That is the whole point of the handoff.
It is boring on purpose
Server-rendered pages, one database, one deploy. Fewer moving parts than a front end, a backend, an edge function, and a hosted database that all have to agree with each other. When something breaks at 3am there is one place to look.
The evidence
The Rails Foundation measured it.
In August 2026 the Rails Foundation commissioned Evil Martians to benchmark coding agents on a real Rails codebase. Stage one: 21 atomic tasks on Writebook, 8 models, 504 runs, $491 in total spend. Claude Opus 5 solved 92% of runs (58 of 63). The cheapest capable model finished all 63 of its runs for 91 cents combined. The report's own conclusion: atomic Rails work is mostly a solved problem for frontier models.
The catch, from the same report: The models mostly write their own version instead of reaching for the framework's built-in API. Recall of the correct Rails API ranged from 8% to 35%. Hand-rolled code is code your team now maintains.
Rails Foundation / Evil Martians, Agents on Rails benchmark, August 2026 (Stage 1: 21 atomic tasks on Writebook, 504 runs)
Why the catch is the job
Read those two findings together. The models get you most of the way, cheaply, in Rails. And they leave behind code that works but does not use the framework: a hand-rolled authentication flow where has_secure_password would do, a custom job runner where Active Job would do, validation logic in a controller that belongs in the database. Every one of those is something the next developer has to understand from scratch instead of recognize.
Closing that gap is what a senior Rails engineer does. Not writing everything by hand, and not accepting whatever the model produced, but knowing which of the two thousand lines should be twenty lines of the framework. That is the difference between a codebase your next hire opens and nods at, and one they quote you a rewrite for.
What this is not claiming
It is not claiming Rails is growing. Ruby is a shrinking share of a growing pie: around 6% of developers in the 2025 Stack Overflow survey, and JetBrains puts it in long-term decline. It is still a legitimate, productive stack with hundreds of thousands of live sites and Shopify and GitHub on it, but if you want the fashionable answer, this is not the shop.
It is not claiming AI builds whole Rails apps. The benchmark's first stage is atomic tasks; the harder greenfield and multi-step stages were still coming as of the August 2026 report. Rails is a good place to have a model do scoped work with an engineer reviewing it. That is what a run is.
It is not claiming your React app is wrong. Read on.
The obvious question
My app is not in Rails.
Most of them are not. The tools people prototype with (Lovable, Bolt, v0, Replit) mostly produce React or Next.js on top of Supabase. That is fine, and it is not a reason to rebuild by itself.
The diagnostic answers the actual question, which is not "what stack is this" but "is the foundation sound." Sometimes the answer is: keep what you have, fix three specific things, here is what they are. You get that in writing and you can take it to anyone. When the answer is that the data model, the auth, and the jobs are structurally wrong, rebuilding the core in Rails is usually cheaper than repairing it in place, and it leaves you with something maintainable by a person, which the original was not.
The one line I will not cross is forcing Rails onto an app that does not need it. That would be the same mistake the AI tool made, in the other direction.
The stack, concretely
- Ruby 3.4, Rails 8. Server-rendered HTML with Hotwire for the interactive bits.
- PostgreSQL. Invariants that must always be true go in the database, not in a callback.
- Tailwind for the interface, so a designer can restyle without a rewrite.
- Standard, public gems only. No in-house framework, no private registry.
- Solid Queue or Sidekiq for jobs. Encrypted credentials for secrets. Kamal or a managed host for deploy.
- A containerized development environment so the next developer runs it in minutes.
Steam it up.
Twenty minutes on a call, free. You show me the app or describe the idea, and I will tell you which run you need, or that you do not need one. No deck, no discovery process, no sales sequence.
Book the 20-minute callbill@atomiclocomotive.com · Austin, Texas · Usually replies same day