Rewrite or Repair? How to Decide Without Reading a Line of Code

It usually arrives about six weeks after a senior hire starts. The conclusion is delivered with conviction, often with relief: the existing product cannot be saved, and the fastest path forward is to rebuild it properly. Three months, maybe four. Then everything will be clean.

You are not equipped to argue about the code, and you should not try. But this is a capital allocation decision, and those you can absolutely evaluate. What follows is how to run that evaluation without anyone having to explain architecture to you.

The question behind the question

Every engineer who inherits someone else work wants to rewrite it. This is not cynicism — it is a well-documented and fairly rational bias. Reading unfamiliar code is slow and unrewarding; writing new code is fast and satisfying. The person making the recommendation is sincere and is also, structurally, the least neutral party available.

So the first move is not to say yes or no. It is to convert "we should rewrite it" into two priced options with dates attached, and to notice that only one of them has ever been estimated.

What each option actually costs

Put both on one page. The numbers below are the shape of a typical four-person team on a pre-seed product — substitute your own, the comparison is what matters.

The row that decides most of these arguments is the last one. Repair is a series of small bets you can stop making. A rewrite is one large bet you cannot unmake once the team has started deleting things.

Three conditions that actually justify a rewrite

There are real cases. If any of these is true and you can state it in a sentence your investors would accept, a rewrite is a legitimate answer.

1. The product structurally cannot do what you are about to sell. Not "it would be hard" — cannot. You signed a customer who needs something the current shape of the product forbids, and no amount of patching changes that.
2. The cost of change is still rising after honest repair. You fixed the obvious things, wrote down how it works, added tests — and delivery is still getting slower month over month. That is a structural verdict rather than an opinion.
3. Something underneath is genuinely dead. A core dependency is unmaintained, unsupported or no longer secure, and nobody ships it any more. This is rare, verifiable, and not a matter of taste.

Notice what is absent. "It is messy", "it is not how I would have done it", "the framework is old", and "I do not like the way it is organised" are all real observations and none of them is a business case. They describe discomfort, and discomfort is fixed by documentation and a few weeks of cleanup, not by a quarter of rebuilding.

What repair looks like when it works

Repair has a bad reputation because it is often imagined as endless patching. Done deliberately it is a short, bounded project with a visible end.

• Describe what exists. Two or three days of writing down the parts, how they connect and which decisions were deliberate. Everything after this is cheaper.
• Make the release path repeatable. One documented route from approved change to live, runnable by anyone.
• Put automatic checks on the paths that touch money. Sign-up, payment, and your core promise. Nothing else yet.
• Fix the three things that actually slow people down. Every codebase has a small number of places where all the pain lives. Find them, fix those, stop.

That is typically two to four weeks of one experienced person, and it changes the ramp-up cost for everyone you hire afterwards — the compounding effect described in Why Fast-Built Products Get Expensive Right After Funding.

A rewrite replaces a product you understand badly with a product that does not exist yet. For a few months you have neither.

The failure mode nobody plans for

The rewrite that quietly never finishes is the most expensive outcome in this whole decision, and it is common. The pattern is always the same: the new version reaches roughly eighty per cent of what the old one does, at which point every remaining item is an obscure edge case that a real customer depends on. Meanwhile the old product still has to be kept alive, so the team is now maintaining two things instead of one.

Teams rarely abandon a rewrite outright. They just stop talking about the finish date. If you take one precaution from this article, make it this: agree in advance what "done" means, in writing, before anyone starts.

How to decide in one afternoon

1. Ask for both options on one page, with dates. Not a document — a page. If the rewrite cannot be scoped to a date, that is your answer.
2. Ask which of the three conditions above applies, and ask for it in one sentence. Vagueness here is meaningful.
3. Ask what ships to customers during the rewrite. Write the answer down and imagine reading it to your board in month three.
4. Ask for the three-week version. Compare it to the three-month version and see how much of the value is in the first one.
5. If you still cannot tell, buy a second opinion from someone with no stake in the outcome. Two weeks of an outside read is cheaper than one wrong quarter by an order of magnitude.

If you do rewrite, do it in slices

Occasionally the case is real. When it is, refuse the big-bang version anyway. Replace one piece at a time, keeping the product live throughout, so that value arrives continuously and you can stop at any point with something that works.

It is slower on paper and faster in practice, because it is the only version that reliably finishes. And it preserves the property that matters most while you are still pre-Series A: at every moment, you have a product you could show to a customer tomorrow.