Rewrite vs. Refactor: The Budget Argument That Actually Lands

Published by CodeNicely, the product studio founded by Meghal Agrawal and Ujjwal Agrawal in 2017

For: A UK Series A SaaS founder whose CTO is asking for six months and £300K to rewrite the core platform, and who needs to decide whether that ask is justified before the next board meeting

If more than 40% of every sprint is being eaten by compatibility fixes, workarounds and regression firefighting rather than new functionality, your CTO is probably right that something has to change — but almost certainly wrong that the answer is a full rewrite. The decision between rewriting and refactoring is not a taste question or an engineering preference. It turns on one measurable ratio most founders never track, and on an honest reading of what a six-month code freeze does to a Series A revenue plan. This post gives you the argument you can take into the next board meeting.

Start with the number your CFO will actually believe

Before you argue sequencing, you need a shared view of what the current system costs you every month you keep it. Not the AWS bill. The hidden tax.

Stripe's Developer Coefficient study of over 1,000 developers found engineers spend an average of 17.3 hours per week on maintenance and bad code — 42% of a 41.1-hour week. Of that, 13.5 hours go specifically to technical debt. Deloitte's Tech Trends 2024 analysis puts the figure at roughly 33% of total engineering time, and Stack Overflow's 2024 Developer Survey of 65,000+ developers found tech debt is the single biggest workplace frustration for 62–63% of professionals — twice the rate of the next complaint.

Translate that into language your CFO uses. If your engineering team costs £1.2M a year fully loaded, somewhere between a third and 42% of that — £400K to £500K annually — is already being spent on the legacy system. You are not deciding whether to spend money on tech debt. You are deciding whether to keep spending it invisibly, forever, or spend it visibly, once, with a defined end date.

That reframing is the single most useful move you can make before the board meeting. The question stops being "should we fund a £300K rewrite?" and becomes "we are already paying £450K a year in hidden debt tax — what is the lowest-risk way to stop paying it?"

The metric that decides rewrite vs refactor

Here is the number almost no one measures and the one that actually matters: what percentage of each sprint's capacity is consumed by compatibility work, regression fixes and dependency wrangling, versus net new functionality?

Pull the last six sprints. For each ticket closed, tag it as one of:

• Net new — a feature a customer or revenue line asked for
• Compatibility — making old code work with new code, library upgrades, framework patches, workaround plumbing
• Regression — fixing something that broke because of a prior change
• Keeping the lights on — ops, incidents, support escalations traced back to the codebase

Add the bottom three. Divide by total sprint points.

The thresholds we use:

• Under 25% — healthy. Refactor opportunistically inside normal sprints. Any rewrite proposal is almost certainly premature.
• 25–40% — stressed but recoverable. A dedicated refactor track (20% of capacity, ring-fenced) run alongside product delivery usually brings it back under 25% within two to three quarters.
• Over 40% — compounding failure. Refactor cycles stop paying for themselves because every fix touches code that is itself fragile. This is the point at which a bounded rewrite of the specific blocking module becomes cheaper than another eighteen months of workarounds.
• Over 60% — the team has effectively stopped shipping. Something more aggressive is justified, but even here "rewrite everything" is almost never the right answer.

Notice what this metric does. It replaces the CTO's gut feeling ("the architecture is wrong") and the CFO's gut feeling ("engineers always want to rewrite") with a number both of them can argue about. If your CTO cannot produce this number for the last six sprints, that is itself the answer: you do not yet have enough evidence to commit £300K.

The real cost of doing nothing

Your CFO will reasonably ask: what if we just keep going? Four line items usually clinch the business case.

1. The absorbed-headcount cost

Using the Stripe and Deloitte figures above, calculate the fully-loaded cost of the engineering hours currently absorbed by debt. For a 10-person team at £120K loaded, that is £360K to £500K a year — a recurring cost, not a one-off. Compare to the rewrite ask on a three-year horizon, not a one-year one. The arithmetic usually surprises both parties.

2. The feature opportunity cost

What is on the roadmap that your sales team is already losing deals without? For a Series A SaaS, this is almost always more quantifiable than people think. Pull the last two quarters of lost-deal reasons from your CRM. If "missing integration with X" or "cannot handle our data volume" appears in more than 15% of losses, you have a direct revenue number to pin to the delay. Gartner and Deloitte data referenced in industry analyses of legacy modernisation show 60–80% of enterprise IT budgets go to maintaining existing systems, leaving only 20–40% for anything new. You are almost certainly in that trap already.

3. The audit, compliance and breach exposure

Unsupported runtimes, unpatched dependencies and shadow data flows are increasingly a line item in SOC 2, ISO 27001 and UK GDPR audits. If your platform runs on a framework version that no longer receives security patches, your insurer and your enterprise prospects' security teams will eventually ask about it. This is a question for your lawyer and your auditor to size specifically — do not let anyone (including this post) tell you what the exposure is in pounds without a proper review — but "we have an unquantified compliance tail" is itself an answer the board should hear.

4. The hiring and retention cost

This one is uncomfortable but real. The Stack Overflow 2024 data showing tech debt as the #1 developer frustration translates directly into attrition. Senior engineers leave teams where every sprint feels like firefighting. Replacement cost for a senior backend engineer in London is routinely quoted at 6–9 months of salary when you factor in recruiter fees, ramp time and the productivity dip. Two unplanned senior departures and the "we cannot afford the rewrite" position becomes expensive.

Why full rewrites usually fail — and the sequencing that works

The case against the big-bang rewrite is not ideological. It is empirical. The McKinsey and University of Oxford study of over 5,400 large IT projects found they run 45% over budget on average and deliver 56% less value than predicted. That is the exact risk profile of a six-month, £300K platform rewrite. Applied honestly, your CTO's £300K ask has an expected cost closer to £435K and an expected delivered value closer to 44% of what was promised.

Worse: during those six months, product delivery slows or stops. Your Series A plan assumed a certain revenue velocity. Two quarters of frozen feature output against a backdrop of competitors shipping is not a technical risk. It is an existential one.

The alternative is the strangler fig pattern — named after the fig that grows around a host tree until the host is gone — and it is now the default modern approach for a reason. McKinsey's 2023 'Rewired' research, summarised in modernisation analyses, found that companies modernising incrementally recover their investment 3× faster than those attempting full rewrites, achieving equivalent debt reduction within 24 months — while continuing to ship.

What a strangler-fig sequence actually looks like

For a typical Series A SaaS monolith, the sequence usually runs:

1. Instrument and measure (2–4 weeks). Get the sprint-capacity ratio above. Map module-level change frequency and incident frequency. The modules that score highest on both are your rewrite candidates. Everything else gets refactored in place or left alone.
2. Extract the highest-pain module behind an API boundary (6–10 weeks per module). Usually this is auth, billing, the reporting engine, or whichever component is in every incident post-mortem. The old code keeps running. The new module takes traffic behind a feature flag.
3. Shift traffic incrementally (2–4 weeks). 5%, 25%, 50%, 100%. If anything breaks, flip the flag back. The old module stays as fallback for one or two sprints, then gets deleted.
4. Measure the sprint ratio again. If it has dropped meaningfully, pick the next module. If it has not, you targeted the wrong module — stop and re-measure before spending more.

The critical property: each increment pays for the next. You are not asking the board for £300K up front. You are asking for one increment, with a defined scope, a defined outcome (sprint ratio drops from 45% to 30%), and a decision point before the next tranche. That is a business case a CFO can approve.

The spending shape to propose

Rather than one £300K line item, structure the ask as three to four tranches, each with its own gate. The cost of any single tranche is driven by a small number of specifics: how many modules you are extracting, how much live data has to be migrated without downtime, how many external integrations the module touches, and whether you have the test coverage to move safely or have to build it as you go.

To give you a sense of the shape, consider an illustrative example — numbers made up to show the structure, not a quote: a first increment extracting a single high-pain module (say, the reporting engine), with two existing integrations and reasonable test coverage, might reasonably be scoped as a 10–14 week engagement. A second increment tackling billing, which touches payment providers and has stricter correctness requirements, might take longer and cost more. A third tackling the data layer, usually the hardest, longer still. Each tranche's budget is set after the previous one closes.

The specifics that would turn any of this into a real quote rather than a shape:

• Which specific modules, in what order, based on the measured sprint-ratio data
• The current test coverage percentage and CI maturity (this is the single biggest cost driver)
• Whether live customer data needs zero-downtime migration or can tolerate a maintenance window
• How many third-party integrations each module touches and whether their contracts are stable
• Whether your in-house team is co-building (cheaper, slower) or the work is fully outsourced (faster, more expensive, higher handover risk)

Any firm that gives you a number without asking these questions is guessing. A proper modernisation scoping conversation should produce a tranche-by-tranche plan with its own assumptions written down, so you can see what moves the number.

What the business has to supply

One failure mode worth naming: founders approve the budget, then discover the project stalls because the engineering team cannot get the business inputs it needs. For a strangler-fig sequence to work, you have to commit to:

• A product owner with decision rights for each module being extracted. Not a committee. One person who can resolve edge-case questions in hours, not weeks.
• Access to real production data (anonymised where needed) for the team doing the extraction. Synthetic data hides the bugs that matter.
• A frozen scope per tranche. The temptation to add "while we're in there" features is what turns a 10-week increment into a 20-week one. New features go on the normal roadmap, not into the modernisation tranche.
• A measurable success criterion per tranche — usually the sprint-ratio drop, plus an incident-rate drop for the extracted module. Agreed before work starts.

The argument, condensed

What to say in the board meeting, in roughly this order:

1. We are already spending an estimated £X a year on hidden debt tax (your sprint-ratio number × loaded engineering cost). That is the baseline, not zero.
2. Independent research — Stripe, Deloitte, Stack Overflow — puts this in the normal range for a company at our stage, but it is above the threshold where it stops improving on its own.
3. A full rewrite would carry a 45% average overrun and deliver 56% less than promised, based on McKinsey/Oxford data on 5,400+ projects. We are not proposing that.
4. We are proposing a strangler-fig sequence: three to four bounded increments, each with its own scope, budget and success metric, each gated by the previous one's results. McKinsey's own research shows this recovers investment 3× faster than a rewrite.
5. We are asking the board to approve the first increment only. The second increment comes back for approval once the first closes.
6. If the first increment does not move the sprint ratio by the agreed amount, we stop and reassess. The downside is bounded.

That is an argument a CFO can say yes to without betting the company, and one a CTO can execute without being set up to fail. It is also, not coincidentally, the argument that reflects what the evidence actually says about modernisation outcomes — companies in the top 20% for managing technical debt grew revenue 20% faster than the bottom 20%, according to McKinsey's 2022 analysis of 220 companies. The upside of doing this well is not just "faster feature delivery." It is a measurable revenue effect.

Where this approach is bad

Honesty requires naming where strangler-fig is the wrong answer. If your platform runs on a runtime that is already end-of-life and unpatched (older PHP, unsupported .NET Framework versions, a database your cloud provider is deprecating), you may not have the luxury of a 24-month incremental path. If the core data model is fundamentally wrong — not just awkward, but modelling the wrong entities — refactoring around it indefinitely postpones a reckoning you will eventually have to face. And if you are in a regulated vertical where the current system cannot be audited at all, the compliance clock may force a timeline the business case alone would not.

In those cases the conversation is different, and the honest answer is that a larger rebuild may be unavoidable. But those are the exceptions. For the typical Series A SaaS with a five-to-ten-year-old codebase that has become hard to change, the incremental sequence is almost always the better bet.

Frequently Asked Questions

How do I know if my CTO's rewrite proposal is actually justified?

Ask for the sprint-capacity ratio — the percentage of the last six sprints consumed by compatibility work, regressions and keeping-the-lights-on tickets versus net new features. If it is under 40%, a bounded refactor track almost certainly solves the problem for less money and less risk. If it is over 40% and concentrated in one or two specific modules, a targeted rewrite of those modules (not the whole platform) is reasonable. If your CTO cannot produce this number, that itself is the signal to pause.

What drives the cost of a legacy modernisation project?

The main drivers are the number of modules being extracted, current test coverage (low coverage means building the safety net before you can move safely, which is often 30–40% of the work), whether live data needs zero-downtime migration, the number and stability of third-party integrations, and whether your in-house team is co-building or the work is fully outsourced. Any firm willing to quote a number without asking these questions is guessing. A proper scoping conversation should produce a tranche-by-tranche estimate with the assumptions written down.

How long does a strangler-fig modernisation typically take?

It depends on how many modules need to move and in what order, but the shape of the work is usually a 2–4 week measurement and planning phase, followed by 6–10 week increments per module, each with its own gate. McKinsey's research suggests incremental approaches reach equivalent debt reduction to a full rewrite within about 24 months while continuing to ship product throughout — compared to a 6-month-plus freeze with a full rewrite. The honest answer for your specific case needs the scoping specifics listed above.

Should we hire more engineers instead of modernising?

Usually not. If 40%+ of each sprint is going to debt, adding engineers scales the debt cost linearly without changing the ratio — you spend more money to make the same proportion of progress. Worse, new engineers onboarding into a difficult codebase take longer to become productive and are more likely to leave within 12 months. Fixing the ratio first, then hiring, generally produces better returns than the reverse.

What about the compliance and security risk of staying on the old system?

This is a question for your lawyer and your auditor to size against your specific obligations — SOC 2, ISO 27001, UK GDPR, FCA requirements if you touch regulated data, and your cyber insurance policy. What you can say in the board meeting is that unsupported runtimes and unpatched dependencies create an exposure that is currently unquantified, and that quantifying it is itself a reason to engage specialist advice. Do not let anyone give you a pounds-and-pence number on this without a proper review.