Why I almost never approve a full rewrite of your product

A logistics founder called me set on throwing three years of product in the bin and starting over. I spent the whole call talking him out of it. A full rewrite is the decision that looks most like courage and most often turns out expensive, and there is almost always a duller path that ships better.

On a Tuesday in April, the founder of a logistics startup called me with his mind already made up. Three years of product, a team of five, and the line I hear about twice a month: "the codebase is rotten, let's rewrite the whole thing from scratch and do it right this time." He wanted Revin to run the rewrite. I spent the next forty minutes of that call trying to talk him out of it.

Not because the codebase was good. It was genuinely bad; I had taken a look before the call. The point is different: a rewrite from scratch is almost always the most expensive decision a founder signs off on all year, dressed up as courage. I have watched that movie enough times to be scared of it.

If you have a vendor, a developer, or your own tired brain suggesting you wipe it all and start over, this piece is about the bill nobody puts on the rewrite slide.

The urge to start over is not stupid

Let me be fair to the people who want to rewrite. Reading code someone else wrote in a hurry is one of the most thankless jobs in engineering. You open a thousand-line file, there are no tests, the variable names lie, and every time you pull one thread three others move. Against that, the blank page feels like rest. Starting over is the fantasy of every developer who inherited a mess, and I understand the fantasy because I have had it too.

The problem is who profits from it. When a vendor pitches you a full rewrite, they are selling you six, eight, twelve months of fresh work where they barely have to understand what already exists. It is comfortable for them and costly for you: they swap the hard part, reading and fixing what stands, for a fun part that you finance. That is why, when the logistics founder came to me, my first job was to block the easiest sale I could have closed.

The blank page of a new project feels like relief. It is also where the bill starts climbing.

The bill that disappears from the slide

The rewrite reaches the founder as a single number: what it costs to build the new thing. What drops off the slide is the rest of the bill, which is usually bigger. While the new team writes, the old system stays up, serving customers, breaking, charging for maintenance. You pay for two products at once, one dying slowly and one not yet born.

There is also the tax nobody warns you about: you will reintroduce bugs you had already fixed. That weird if-statement in the middle of checkout that nobody understands is usually there because a real customer broke in a specific way back in 2023. The rewrite erases that scar without knowing it existed, and you reopen the wound months later, rediscovering the hard way why the old code was ugly.

A client of mine from 2023, an auto-parts marketplace with around forty thousand SKUs, spent seven months and roughly $68,000 on a rewrite that never replaced the old system. The two ran side by side until cash got tight. When they stopped, they had migrated about 40% of the screens and burned out a whole team. They went back to the old system, now with half the people to maintain it.

Of every ten founders who come to me wanting to rewrite, about eight did not need to. I know that number is biased: the ones who rewrote and won do not call me to brag, so my sample is made of people it went badly for. But even cutting it in half, that is still too many spending for nothing on a decision that felt obvious on a bad night.

Three questions before you rewrite the first line

Before I approve anything, I make the founder answer three questions out loud. They are not clever. They just separate the rewrite that is a need from the rewrite that is fatigue.

• Is it architecture or is it mess? Mess gets refactored without throwing anything away. Genuinely wrong architecture (a database that cannot hold the business model, a stack choice that jams the product) is rare, and it is the one case where a big rewrite tends to pay for itself.
• Can you freeze features for six months? An honest rewrite means you stop evolving the product while it is rebuilt. If the business cannot survive that freeze, the rewrite starts out losing to the competitor who kept shipping.
• Does anyone still understand the current system? If the knowledge left with the old vendor, you will not rewrite the product: you will rewrite the same mistakes in the dark, without even knowing what they were.

If the answer to any of the three makes you uncomfortable, the rewrite will probably hurt more than the codebase you want to throw out.

A historic building restored with scaffolding outside while life goes on inside. That is how an old codebase improves without closing its doors.

The dull path that usually wins

There is an alternative nobody puts on a slide because it is unglamorous: improve what stands, one piece at a time, with the product live the whole way through. The jargon for it is the strangler fig. You grow the new around the old and choke it out module by module until the old one disappears on its own. No big cutover day, no pretty photo. Just a release every week.

That is what we ended up doing with the logistics startup. No starting from zero. The first two weeks were pure reading: mapping what existed, writing tests over the current behavior to lock down what already worked, and finding the rottenest module. It was the routing engine. We rewrote it behind a stable interface, the rest of the system never noticed the swap, and we moved to the next one. About six months later, most of the critical code was new and the product never went down for a single day. That is the kind of decision we pull apart right in the diagnostic.

Rewriting behind an interface is not slower than a big bang. It is usually faster, because every week ships something you can test with real users, instead of betting six months on a single flip that might not even go live. The dull part is exactly the part that protects your cash.

Back to that Tuesday call

The logistics founder did not rewrite. We strangled the worst part first, he kept selling the product during the work, and the dream rewrite he had quoted with another vendor, nearly a year of standstill, never had to exist. He told me afterward that the most profitable decision of that year was the one to do nothing heroic.

If someone is pushing a from-scratch restart on you right now, be suspicious of whoever gains from the delete button. Before you sign, half an hour looking at your codebase with people who read code for a living is worth it, and that is usually where the conversation starts.