Back in 2000, Joel Spolsky called a full rewrite the single worst strategic mistake a software company can make. Twenty-five years later it's still mostly true, and AI has not changed that as much as people hope.
Almost every founder who calls me about an old system already has the answer they want to hear. "Let's rewrite it, properly this time." Sometimes that's right. More often it is the expensive road to the same problems, plus a year of lost roadmap. Here is how I decide.
First, name the pain
Be specific, because the fix follows the diagnosis. The complaints land in a few buckets.
- You can't hire for the stack, and nobody left understands it.
- Every release is scary. You ship holding your breath.
- It sits on an unsupported version with holes you can't close.
- A change that should take a day takes a fortnight.
- It buckles under load.
One question sits under all of them. Is the problem the code, or the architecture and the data model? Messy code is cheap to clean. A wrong core model is not. That is surgery.
When hardening is the answer
This is the case far more often than founders expect. If the system still makes money, the architecture holds and the data model is roughly right, you almost never need a rewrite. Ugly code is cheap to fix next to rebuilding from nothing. So you harden the risky parts, add tests until change stops being frightening, get current on the version, and tidy up while it keeps earning.
When a rewrite earns it
A few situations do call for one. The data model is wrong at the core and every feature fights it. Maybe the stack is dead, nothing left to host or patch. Or the product needs something the current shape can't carry. Even then, the big-bang version, build for a year and flip a switch, is the one that sinks projects. Replace it piece by piece instead.
The middle path most people skip
Piece by piece is what I reach for most. You grow the new parts beside the old system and move one slice at a time, until the old one is gone. The app keeps working the whole way, with no feature freeze and no launch-day drama. Less satisfying than a clean slate. Almost always the right call.
Where AI earns its keep
This is the part that changed in the last two years. AI is genuinely good at the slow, mechanical side of modernization. It reads a fifteen-year-old codebase and tells you what a function does. It writes the tests you never had, so refactoring stops being a gamble. And it grinds through version bumps and the same edit across hundreds of files. What it will not do is choose the architecture or recover the business rules nobody wrote down. That judgment is still yours. Used well, it takes months off the boring work and changes none of the thinking.
A four-question rule
When I'm on the fence, I answer four things.
- Is the data model wrong at the core? Yes leans rewrite, no leans refactor.
- Can you run and deploy it safely today? If no, fix that first, before any big call.
- Can you hire and keep people for this stack? If no, that pushes toward moving onto something current.
- Does it still make money? Then protect it. Change it slowly. Don't bet it on a rewrite.
Sitting on an old system and not sure which way to go? I'll look at it, tell you straight whether to harden, modernize, or rewrite, and my team at Fingoweb can do the work.