Refactor incrementally in most cases — rewrites take longer than estimated, freeze feature delivery, and reintroduce bugs that were fixed years ago. Rebuild only when the platform is unsupported, the technology cannot meet a hard requirement, or nobody can safely change the code. The strangler pattern gets most of the benefit of a rewrite without the risk.
Every engineer who inherits a codebase wants to rewrite it. Sometimes they are right. Usually the mess encodes years of business rules nobody has written down.
Typical rewrite overrun
The lower-risk path
The hidden rewrite cost
The right default
Improve the code you have, in the areas you are already touching. Continuous delivery never stops.
New system grows around the old one, route by route, until the old one is unused and can be removed.
Build the replacement, then cut over. Highest risk, occasionally the only honest option.
Tests that pin current behaviour — including the bugs — so changes cannot silently break something.
Often the actual need. An unsupported framework version is a security problem, not an architecture one.
A paid audit that tells you which of these you need, including 'leave it alone'.
| Rebuild when | Refactor when |
|---|---|
| Platform is unsupported and unpatchable | Framework is old but maintained |
| Technology cannot meet a hard requirement | It is slow but fixable |
| No developer will work on it | It is unpleasant but workable |
| No tests and no safe change path | Tests can be added incrementally |
| Cost of change exceeds cost of replacement | Changes are still tractable |
| Product direction has fundamentally changed | Same product, tired code |
New functionality is built in the new system, traffic is routed piece by piece, and the old system shrinks until it can be removed.
Feature delivery continues throughout, each step is independently reversible, and the project can be paused if priorities change. It is slower in total than a clean rewrite would be if a clean rewrite ever went to plan.
Plan for two to three times the initial estimate. The gap is almost entirely undocumented business rules discovered during the work — which is precisely the part nobody can estimate upfront.
Sometimes. Also, every engineer finds unfamiliar code unmaintainable. Ask for specifics: which changes are impossible, and why. Concrete examples distinguish a genuine problem from unfamiliarity.
Yes, and it is common. We start with a paid audit so you get an honest assessment before committing, including whether the honest answer is that it does not need our involvement.
Frequently the best option. The frontend is where users feel the age, and it can usually be replaced behind the same API incrementally, page by page, with far lower risk than a full-stack rewrite.
How we think about this work, in more depth.
Comparison
A 30-minute call, then a written proposal with scope, price and timeline within two to three working days. No retainer required to get a real number, and no obligation if the answer is that we are not the right fit.