The real cost of a rewrite nobody scoped

Every engineering org eventually has this conversation: the codebase is painful, velocity is dropping, and someone senior says the two-word sentence that ends the debate before it starts — "rewrite it." It's appealing because it sounds decisive and because everyone can picture the clean version in their head. What almost never gets pictured with the same clarity is the actual cost, because that cost doesn't show up until months in, and by then the decision is sunk.

The cost that isn't in the estimate

Whatever number engineering gives you for a rewrite, the real number is larger, for a structural reason: the old system encodes years of edge cases nobody remembers deciding on. The rewrite doesn't just have to replicate what the system does — it has to rediscover what the system does, one support ticket and one angry customer at a time, because most of that knowledge was never written down. This is why rewrites reliably take 2–3x their original estimate, and why the last 20% consistently takes as long as the first 80%.

The cost that shows up on the roadmap

A rewrite freezes the old system's feature velocity without freezing the market. Competitors keep shipping. Customers keep asking for things. Every feature request during the rewrite window becomes a choice between building it twice — once in the dying system, once in the new one — or telling the customer to wait for a launch date that, per the paragraph above, is going to move. Boards rarely price this in when they approve the rewrite; they price it in six months later when growth has visibly stalled.

The cost that's actually a symptom

Here's the harder truth: most of what gets called "the codebase is unmaintainable" is actually "we never built the discipline to keep it maintainable as we grew," and a rewrite doesn't fix that discipline gap — it just resets the clock on it. Teams that rewrite without changing how they build end up with a new codebase that degrades on the same trajectory as the old one, just from a later starting point. I've seen this happen twice at the same company.

Three questions before you approve one

First: can you name the specific capability the current architecture cannot support, versus a general feeling that the code is messy? Second: is there a narrower fix — extracting one subsystem, adding a boundary, retiring one especially toxic module — that gets 70% of the benefit at 20% of the cost and risk? Third: what changes about how the team builds and reviews code, so the new system doesn't arrive at the same place in three years?

If you can't answer the first question specifically, you don't have a rewrite decision yet — you have a diagnosis to do first. See how a quality architecture engagement scopes that diagnosis.

Subscribe: RSS