A boring choice that compounded
After three years and 250 deploys per month, we still ship more features per engineer than any other team we benchmark against. That is not a framework achievement on its own, but the framework is doing a lot of the carrying.
Rails gets a lot of grief for being "old". We have not found anything better for solo-to-50-engineer teams, and we have looked twice — once seriously, in 2024, with a working prototype.
What we get for free
The list is unglamorous, which is the point. Every item is something a newer stack would have had us assemble ourselves:
Migrations that a junior engineer can write and a senior can review in a minute.
A background job story, a mailer story, and a caching story that all assume each other.
Fixtures and factories, so a test that needs six related records is six lines.
Thirty thousand people who have hit the exact error message you are reading.
Where it hurts
Boot time. Our test suite boots in 9 seconds and that is after a year of trimming; the frontend equivalent boots in under one.
The frontend boundary, honestly. We run Relay against a GraphQL schema generated from Ruby, and every so often the two worldviews disagree in a way that costs an afternoon.
And the escape hatches are too easy. A callback that should have been an explicit step is always the path of least resistance, and we have 260 concepts partly because we kept taking it.
The 2024 prototype
We spent six weeks in 2024 rebuilding the deals surface on a Node stack, end to end, with the same feature set. Not a spike — a real prototype with tests, a deploy, and two engineers on it.
It was faster to boot, slower to write, and about the same to read. The part that decided it was the fourth week, when we had to build the audit trail and discovered we were reimplementing three things Rails gives us in one line each.
We keep the branch around. Twice a year someone asks the question again, and having a real answer rather than an opinion has been worth the six weeks on its own.
The honest trade
We are not arguing Rails is fastest, or most modern, or that it would be our choice for a real-time collaborative editor. We are arguing that the total cost of a feature, from idea to production to the day someone else has to change it, is lower here than anywhere else we have worked.
Pick the stack where your team can be wrong cheaply. Most of what you build will be wrong at least once.