DHH is rewriting HEY in Rust. Should you rewrite your Rails application?

At the Rails World 2026 opening keynote, David Heinemeier Hansson announced that 37signals is rebuilding HEY — its email service — as six native applications with the backend rewritten in Rust, with AI agents producing the code. His reported figures are striking: around 99% less CPU and 95% less memory, with a back-of-the-envelope suggestion that HEY's peak traffic could run on a single Raspberry Pi. He was open that these are 37signals' own early estimates, and the rewrite is still in progress.

If your board or your CTO has seen this and asked "should we be doing that?", here is the honest answer: for most businesses running an existing Rails application, no — and understanding why it can work for 37signals is the most useful part of the story.

Disclosure up front: we are a Rails support and maintenance company, so we have an interest in this argument. We would ask you to weigh the reasoning rather than the source.

Writing code was never the hard part

AI tools have genuinely changed the cost of producing code. What they have not changed is the cost of understanding a system that a business already depends on — and understanding is where the risk of a rewrite lives.

A long-standing codebase is not just instructions for a computer. It is the accumulated record of every edge case the business has ever hit: the tax rule that applies in one situation, the email that must go out at a particular step, the workaround for a supplier's broken API, the report a regulator expects formatted just so. Much of this institutional knowledge is not documented anywhere else. It exists only as behaviour encoded in the system — and in the memory of the people who have maintained it.

This is what makes rewrites dangerous. The replacement looks functional. It meets the requirements everyone remembered to write down. Then, months after launch, the business discovers the requirements nobody remembered — usually when a customer complains, a payment fails or a compliance report comes out wrong. Retrofitting those behaviours into a finished rewrite is slow and expensive, precisely because the new team never knew why they existed.

Why HEY is different

Look at what 37signals actually has, and the keynote reads less like "rewrites are safe now" and more like a list of preconditions most businesses cannot meet:

• The knowledge is in the room. 37signals built HEY and has operated it for years. The institutional knowledge a rewrite usually destroys is sitting in the team directing the agents. They can review generated code against everything they know the system must do.
• The old system keeps running. The rewrite replaces a live, working service that stays available until its successor proves itself. This is a company that has rewritten Basecamp several times while keeping previous versions running for existing customers — they plan for coexistence, not a leap into the unknown.
• The product shape genuinely changed. HEY is moving from web app to native applications, and its core is a mail server — a well-understood, performance-sensitive workload where Rust's efficiency pays. The rewrite is driven by a real architectural reason, not by the age of the code.
• They can afford to be wrong. A self-funded product company can absorb a rewrite that slips. A business whose operations run on the application usually cannot.

DHH himself framed the Rust choice from the outside — "I don't know any Rust at all. I consider that a feature." That works when you commission a system you understand completely. It is a poor model for replacing a system you understand partially.

The question your board should actually ask

"Should we rewrite?" is usually the wrong question. The better one is: what is the application failing to do, and is a rewrite the cheapest safe way to fix that?

In our experience taking over inherited applications, the honest answers are usually unglamorous: it is behind on versions and nobody has planned the upgrades; bugs linger because nobody owns them; there is no monitoring, so problems are discovered by customers; knowledge walked out of the door with the previous developer. All of these are maintenance failures, and all of them have maintenance solutions that cost a fraction of a rewrite — planned upgrades, agreed support coverage, and steady improvement of the system you already have. We have written about the common challenges in supporting legacy Rails applications separately.

A rewrite can still be the right call — when the product's shape is changing fundamentally, when the domain is small and fully understood by the team, or when the existing system genuinely cannot be operated safely. The HEY announcement is a reminder that the cost of that path is falling. It is not evidence that the risk has disappeared.

Where that leaves most Rails businesses

If your application is core to your operations and the people who built it are gone, the highest-value investment is almost never a rewrite. It is making the system understandable again: getting it current, tested around the journeys that matter, monitored, and owned by a team that stays. That is also the work that makes any future rewrite safer — a well-maintained application with living knowledge is the only kind you can sensibly rewrite from.

If you are weighing a rewrite against maintenance and want an honest assessment of your application, talk to us. If we think the rewrite is right, we will say so.