Never Rewrite (Except This Once).

Sooner or later, every founder with a working product hears the sentence: "Honestly, it would be faster to start over."

This essay is about why that sentence is almost always wrong, what it costs when you believe it, and the one time in twenty years I've said it myself.

The price of starting over

A rewrite means paying two mortgages. The old system still has to run, patch, and limp along while the new one gets built, and the new one earns nothing until the day it replaces everything. In between, the roadmap freezes. Your competitors' roadmaps don't.

The deeper cost is invisible. An old codebase is crusted with small, ugly fixes, and nearly every one of them is a lesson somebody paid to learn: the timezone bug from four years ago, the payment edge case that only fires on the 31st, the customer who does everything through bulk uploads. Throw the code away and the lessons go with it. The new system gets to fail each of those exams again, live, in front of your customers.

Why builders pitch it anyway

Joel Spolsky named the real reason back in 2000:"It's harder to read code than to write it." Nobody enjoys spelunking through someone else's decisions. A fresh green field where every choice is yours feels like competence itself. And most working developers have a favorite stack they're fastest in, so the pitch writes itself: this is old, this is messy, we'd move quicker in the new thing.

I've had the itch. Every senior engineer has. In my experience, maybe four rewrite pitches out of five are the itch wearing a business case. The itch is human. Billing a client for it is the part I have a problem with.

The worst case on record

Netscape owned the browser in the late nineties, then decided the next version should be a from-scratch rewrite. Close to three years passed between 4.0 and the 6.0 beta, an eternity in that market, and their share collapsed while Internet Explorer shipped release after release into the vacuum. Spolsky's verdict at the time was that no software company can make a costlier strategic mistake. His essay is twenty-six years old now. Teams still re-run the experiment, and it still replicates.

The accounting question

Here's the frame I actually use. Code is an asset when it lowers the cost of the next change, and a liability when it raises it. Notice what's missing from that definition: how the code looks. Ugly code that ships, earns, and bends when you need it to bend is an asset with bad handwriting.

So the rewrite question is what the current code still earns, and what it would cost to re-earn that from zero. Whether the code is nice to read doesn't enter into it. Run that math honestly and the demolition permit rarely survives.

What repair looks like

Renovation, one course of blocks at a time. Carve a seam around the worst part, replace what's behind the seam, ship it. Next month, the next part. The building stays open the whole time, revenue never stops, and each replaced piece starts paying for itself immediately instead of three years from now. It reads as the slow option and almost never is. Most codebases I've been told were hopeless turned out to be three or four honest seams away from healthy.

The once

And then there's the exception, because I did say the sentence once.

QCal came to me as a small paid audit of an existing events app: a weekend of reading, then a written report. The report was supposed to be a repair plan. But the test I ask of any rewrite,what exactly are we preserving, came back empty. No users to migrate. No revenue to protect. No hard-won lessons buried in the code deep enough to save. The only thing left to preserve was the money already spent, and respect for money already spent doesn't preserve anything. It just spends more behind it.

That was scraping a slab, not demolishing a house. The previous build had done its job: it proved the idea deserved a real platform, under constraints I never had to live with. We started clean, and the platform that came out of it now runs ticketing, payments, and both app stores. The rare honest rewrite exists. It announces itself with an empty answer to "what are we preserving," and it is rarer than anyone pitching one wants to believe.

The question to ask back

If someone tells you your product needs a rewrite, don't argue architecture. Ask two questions. What exactly are we preserving? What does the current system still earn while we replace it? A repair plan survives those questions. An itch usually doesn't.

Never rewrite. Except that once, and yours probably isn't it.