Should we rebuild our software from scratch? Rarely

A replacement quote arrives as a PDF, and by the time it reaches the owner’s desk half the building has decided. Should we rebuild our software from scratch? Almost never, and that document is not what should settle it.

Rebuilding, or a full rewrite, swaps out the code and keeps whatever produced it: the decision layer that let the wrong calls reach it. Rebuild when the business has to do something the current system cannot reach by any route. Everything else is a decision problem wearing a code problem’s clothes.

Should we rebuild our software from scratch?

Rarely, and the case that flips it is narrow. The team that wrote the original says it cannot absorb what is coming, and nobody in the room is disinterested. One test: name the thing the business has to do that the current system cannot reach by the date you need it. If a customer would recognise it in a sentence, a rebuild belongs on the table.

Messy code, an old framework, a team that dislikes working in it: engineering preferences, not a business case. Tidiness is not a capability.

What actually failed: the code, or the decisions above it?

A codebase is sediment. Every shortcut, every deadline nobody pushed back on, every architectural call made by the engineer who happened to hold the ticket settles and hardens. Rebuilding moves the sediment, not the process that laid it down.

Run a quick check, no technical vocabulary needed: name the last three technical commitments worth more than a month of team time, who signed each off, and on what evidence. I have rarely seen the answer survive the first one.

An agency builds what the brief says, an offshore team builds the specification it was handed, the original developers make calls every week that nobody reviews. They were doing what the structure asked. What was missing was never talent.

Nobody had bought the decision seat those calls should have crossed. Leave it empty and the second codebase hits the same wall faster, under a deadline the first never had.

One engagement I ran started here. Part of the product had slowed to the point where it undercut his own demos, and the founder had stopped trusting the codebase he was selling. Nothing was replaced. I made the call to fix it in place, then wrote the change alongside him. Inside two months he went from avoiding that code to demoing it to customers.

Speed was the symptom. What he had lost was confidence, and no replacement quote restores that.

Three questions that settle it in an afternoon

In the engagements I run, the rebuild proposal is usually the one option everyone agrees on. That describes the politics, not the engineering. Three questions I ask before reading a file.

Name one thing a customer will be able to do after the rebuild that they cannot do today. If the answer is about the code, the rebuild is an engineering itch scratched with the business’s money.

Work out what happens to the current system while the new one is built. Someone has to run it, patch it, sell against it and keep the customers already paying, every month of the window. Those months are staffed, and the plan rarely prices them.

Ask which decision, made differently eighteen months ago, would have avoided today’s position. If nobody can answer, nobody is positioned to make the next one either.

You can run all three alone, this week, from your own diary and invoices, the same evidence behind how to tell whether your team is delivering without reading the code. Answer all three with names and dates, and the seat above your code is already filled.

What the rebuild plan does not price

The incentive is never printed on the page. Most rebuild-versus-refactor material I read alongside clients comes from firms paid to perform rebuilds, and none of them can publish “do not do this”. Incentive, not dishonesty. Read the letterhead first, mine included.

These plans sink on two line items. Dual running: two systems, two sets of fixes, one team, for longer than the plan says. Migration is where the schedule actually breaks: data, integrations, customer history, the undocumented behaviours a large customer built a process around.

One question makes a supplier honest about both: what happens to the estimate if the current system still has to ship features throughout? How fast that answer comes back has taught me more than the rest of the document. Evaluating a software development quote is the next job, not this one.

When a rebuild is genuinely the right call

Three situations clear that bar. A capability wall: a new market, a regulatory obligation or a data model the system cannot reach. A dead platform: a runtime or vendor dependency with no supported path forward, where staying put becomes a security and hiring problem. An external constraint with a date on it: a large customer’s assurance requirement, a lender’s condition.

Even then the sequencing changes. The decision layer goes in before the work starts, not after. That order turns quality into the default state of the system rather than a crisis response. It is the ground an engagement built to cut software problems by 80% stands on.

There is also a cheaper shape: replace the part that blocks the business, keep revenue running on the rest, and stop when the block clears, not when the codebase is beautiful. The dividing line is what blocks you, not what looks worst.

What to do with the rebuild proposal on your desk

Three answers, and the proposal only priced one. Rebuild. Replace the part that blocks you and keep the rest running. Or neither, because the code did what it was told and the problem sits above it.

What keeps my own interest out of the answer is the shape of the Technical/Strategic Review: the fee is agreed before I read a line of code, it does not change when the answer is “do neither”, and the document is yours either way.

Two weeks inside the codebase, the team and the roadmap, ending in a recommendation you can hand to the firm that quoted. How a fixed-scope technical direction review starts sets out the steps; the call in front of it decides only whether the work is worth doing.

The person who writes “do not rebuild” is still there in month four, when the fix is half-landed and the team is arguing about the next one. Most recommendations stop before that, and the difference is who owns the outcome once the recommendation lands. If the seat is the open question, start with whether the business needs a CTO yet.

The proposal has a window. Your team is already planning against it. A decision nobody makes gets made anyway, by whoever runs out of patience first.

Six months on you have either paid for the rebuild with nobody accountable for the calls behind it, or spent two weeks getting the answer in writing. If you would rather that choice stayed yours, book the exploratory call.