When to Rewrite Your Codebase vs When to Keep Going

At some point your lead developer, or a new hire, or a consultant you paid for two hours, is going to say the words: “Honestly, it would be faster to rebuild this from scratch.”

It sounds clean. A blank page, no legacy mess, none of the weird workarounds nobody can explain anymore. It feels like relief. It is almost always a trap.

I’ve watched founders burn a year and most of their runway on a rewrite that reached exactly the same place they started. I’ve also seen a handful of cases where a rewrite was the only sane option and refusing it would have killed the company. The whole skill is knowing which one you’re in. That’s what this is about.

Why “Rewrite It” Feels Right and Usually Isn’t

The pull toward a rewrite is emotional before it’s technical. The current code is embarrassing. It’s slow to change. Every new feature seems to break two old ones. Starting over promises to make all of that go away.

Here’s what actually happens most of the time.

You throw away knowledge you can’t see. That ugly function with fifteen special cases isn’t bad code. It’s a scar. Each of those cases is a real thing that broke in production, a real customer edge case, a real payment provider that returns nonsense on the third Tuesday of the month. Rewrite from scratch and you don’t just delete the mess, you delete the lessons. You rediscover every one of them the painful way, live, with real users.

The new version gets over-engineered. This is called second-system syndrome, and it’s almost a law of nature. Freed from the old constraints, the team builds everything they wished they’d had the first time: the flexible plugin architecture, the abstraction for the six database types you’ll never use. The first system was too crude. The second is too grand. It takes twice as long and does less.

You quietly rebuild the same bugs. Every fix in the old code exists because something went wrong once. Start clean and you reintroduce the original bugs one at a time, then fix them again, paying twice for the same lessons.

And the whole time, the business doesn’t stop. Competitors ship. Customers ask for things. But your team can’t build new features, because they’re busy rebuilding old ones. You stand still for months to arrive back where you began.

The Sunk-Cost Trap Runs Both Directions

Everyone warns founders about sunk cost pulling them toward the rewrite: “we’ve spent so long, let’s just start fresh and do it right.” Real trap. But it pulls just as hard the other way, toward clinging to something you should replace: “we’ve already invested two years in this codebase, we can’t throw it away now” is the exact same fallacy wearing a different coat. Past spend is gone either way, and it should not be in the decision. The only question that matters is forward-looking: from today, which path gets you to a healthy product for the least time and money?

Keeping a genuinely broken system alive out of loyalty to the money already spent is how founders end up with a codebase that gets more expensive every single month while they insist things are fine.

When a Rewrite Actually Is the Answer

I’m not against rewrites. I’m against unnecessary ones. There are four situations where starting over is genuinely the right call, and they’re narrower than people think.

A real architectural wall. Not “this is annoying to change” but “the foundation physically cannot do what the business now requires.” You built a single-tenant app and now you need multi-tenant. You built on a database that cannot handle your data model. When the core assumption is wrong and everything sits on top of it, patching won’t save you.

Code no competent developer can safely touch. There’s a difference between messy and radioactive. Messy is slow. Radioactive is when any change has unpredictable side effects, there are no tests, and even good engineers refuse to touch certain files. If skilled people can’t safely make changes, the codebase has stopped being an asset.

Security or dependency rot. The framework is years past end of life, the language version no longer gets security patches, core libraries are abandoned. Sometimes the safe path forward genuinely runs through a rebuild rather than an upgrade you can’t perform.

Total key-person lock-in. One person built it, only they understand it, nothing is documented, and they’ve left or are about to. If the knowledge lives in one head and that head is walking out the door, you may be rebuilding whether you like it or not.

A fitness platform we rebuilt was a different call, and it shows a rebuild is not all-or-nothing. Their discovery work was genuinely excellent, and so were the designs. We kept both. What we threw away was the implementation, which was built on an architecture that could not work. Starting the code from zero while keeping months of good thinking and design is not the same as starting over.

The Third Option: Replace It Piece by Piece

The least dramatic option is also the one you hear about least, because it makes for a boring pitch. The choice is not binary. It’s not “suffer forever” versus “burn it down.” There are two proven approaches that capture most of the upside of a rewrite without betting the company.

Incremental replacement, sometimes called the strangler pattern. Instead of one enormous switchover, you replace the system piece by piece. You stand the new code up alongside the old, route one feature or module through the new version, confirm it works, then move the next. The old system shrinks until there’s nothing left of it. The name comes from strangler fig vines that grow around a tree and gradually take its place. You keep shipping the entire time, and every step is small and reversible.

One loyalty platform is this middle path in practice. Their original agency had been hired to fix a specific problem, and they fixed it correctly. The one thing that agency was never told was what was coming next: expansion into several new markets. The build was fine for the job it was scoped for, and it started to crack the moment we needed it to do more. We did not throw it out. We built on the core, replaced the mobile app, and then, piece by piece, strangled the old backend, rebuilding it gradually underneath a product that stayed live the whole time. No dramatic big-bang rewrite. Just steady replacement.

Refactoring in place. You improve the existing code without changing what it does, in small safe steps, guided by tests. You pay down the debt that actually hurts and leave the rest alone. No dramatic rebuild, just steady structural improvement while the product keeps running and earning.

Both share the thing that big-bang rewrites lack: you’re never far from a working product, and you can stop at any point and still have something that ships.

The First Question Isn’t About the Code. It’s About the Team.

Before you approve any of this, sit with the uncomfortable possibility. A struggling team will almost always blame the codebase, because a rewrite feels like a fresh start and a fresh start feels like hope. But if the same people rebuild it with the same habits, you get the same mess in a newer language a year later. I’ve seen it happen. Twice.

Ask honestly: is the code slow to work in because it’s genuinely bad, or because there are no tests, no code review, nobody who understands the whole system, and estimates that are wrong every single time? Those are team and process problems. A rewrite fixes none of them. It just resets the clock on the same dysfunction.

This is exactly why you don’t take this decision on the word of the people who’d do the rewrite. They’re too close, and they have a natural bias toward greenfield work. Get an independent technical audit: a neutral senior engineer who doesn’t get paid either way, who reads the code, talks to the team, and tells you plainly whether you have a code problem, a team problem, or both. It’s a few days of someone’s time against a decision that can cost you a year. This is the kind of read we’re often brought in to do, and I’ll say the obvious thing: an outside partner who profits from a rebuild is not a neutral audit. The value of the audit is precisely that the person giving it has nothing to gain from the answer.

The honest answer, most of the time, is unglamorous: keep going, get disciplined about the parts that actually hurt, and replace them piece by piece. It doesn’t feel as good as a blank page. It just works more often, costs less, and keeps you in business while you do it.