Stabilise, rewrite or pause: how to decide what to do with a codebase that is slowing you down
Most teams asking “should we rewrite?” ask it too early. The first step is to find out where the slowdown really comes from, and to collect enough evidence for the decision to survive a board meeting. In most cases the right answer is to stabilise first. A rewrite is justified only under specific conditions, and pausing is the most underrated option of the three.
Your team knows the code better than any reviewer; the point is to turn what they know into evidence someone else can check.
Why a rewrite feels right, and usually is not
A rewrite is attractive. It promises a clean slate, a modern stack and a happier team. The costs are less visible:
- You rebuild every feature, including the undocumented behaviour customers rely on.
- You run two systems for months, and the old one still needs fixes.
- The roadmap freezes while competitors keep shipping.
- The new system tends to arrive late and incomplete. The classic warning is Joel Spolsky’s essay on Netscape, written in 2000. It still holds.
None of this means rewrites are always wrong. It means they need a stronger case than “the code is ugly”.
The three options
- Stabilise: keep the system and fix its biggest risks in order. Tests around critical flows, monitoring, dependency upgrades, and isolating the worst module behind a clean interface.
- Rewrite: replace the system or a large part of it. The safest form is incremental, replacing one piece at a time while the old system keeps running.
- Pause: stop investing in the system. Freeze features, keep it running and safe, and limit work to essential maintenance until the business question is answered.
The evidence you need before deciding
These six questions give the team somewhere to start. Git history and the issue tracker help check the answers.
- Where does the time go? Take the last 20 merged changes. How many were fixes, firefighting or rework? If most of them were, the code is costing you real delivery capacity.
- Is the pain concentrated? Pain is rarely spread evenly. Cross the files that change most often with the files that appear in bug fixes. If the same few modules come up, you have a stabilisation target, not a rewrite case.
- Can you change it safely? Are there tests around the flows that make money? Can you deploy on a normal weekday and roll back in minutes? If not, fix that first, whatever you decide.
- Is the platform a dead end? An unsupported runtime or framework, dependencies with no maintainers or security fixes you cannot apply are strong reasons to replace.
- Does anyone understand it? If one person holds the whole system in their head, the risk is the team, not the code.
- Does the product still need this system? If you are pivoting, raising or being acquired, the system’s future depends on that outcome.
A simple decision rule
| If you see this | Choose |
|---|---|
| Planned work depends on an unresolved pivot, fundraise or acquisition | Pause that work; keep essential maintenance running |
| The platform is a dead end, or the core data model cannot support where the product must go, and you can run old and new side by side | Rewrite, incrementally |
| Anything else: pain is concentrated, the platform is viable, the team can learn it | Stabilise |
Check which work depends on the business decision before committing engineering time to it.
What a stabilisation target looks like
A good target is narrow: one module or one dependency chain that keeps showing up in fixes, with the evidence written down and tests around the behaviour it touches. A dependency cycle between modules, for example, is a candidate to investigate, not a reason to rewrite. The public evidence packs show the format on open-source code, and the note on technical due diligence walks through one of them, including a warning I would not pass on to a client without checking it first.
What the first 30 days of stabilisation look like
- Week 1: map the hotspots, add tests around the three flows that make money and switch on error monitoring.
- Week 2: upgrade the dependencies with known security issues and make the build fail when tests fail.
- Weeks 3–4: isolate the worst module behind a clear interface, then measure again. If delivery has not improved, check whether the work addressed the actual bottleneck before expanding the scope.
FAQ
How long does a rewrite take? Longer than the estimate, almost always, because feature parity includes behaviour nobody wrote down. Plan in milestones that each replace something in production.
Can we rewrite and keep shipping features? Only with an incremental approach, where new and old run side by side and traffic moves piece by piece.
What do investors think about rewrites? They worry about runway. A credible rewrite plan has milestones, a cost and a point at which you stop if it is not working.
Who should make the call? The CTO or technical lead, with evidence the CEO and the board can read. An outside review helps when the team is too close to the code, or too tired of it. If the codebase was built mostly with AI coding tools, read what to check before you scale a vibe-coded MVP.
Facing this decision now?
Start with the 12-question scorecard: “Stabilise, rewrite or pause? 12 questions to know if you have enough evidence”. It takes 10 minutes. If the answers point to a real decision, the 3-Day Technical Risk Review ($3,500 fixed, excl. VAT) gives you a decision memo, a prioritised risk register and a 30-day stabilisation plan.