“We need to rewrite it.” It’s one of the most common things an engineering team says, and one of the most expensive things a company can act on. Sometimes it’s the right call. Far more often it’s the easiest answer for a team that finds the current code painful to work in — which is a very different thing from the code being genuinely beyond saving.
The classic cautionary tale is real: companies that stopped shipping for a year or two to rebuild from scratch, only to arrive back where they started — minus the year, minus the customers, plus a new set of bugs. So before you commit, pressure-test the decision.
Why “rewrite” is so tempting (and so often wrong)
Reading code is harder than writing it. So to a team, the existing system feels worse than a fresh start — the fresh start is imaginary and therefore perfect. But that imaginary rewrite quietly assumes you’ll re-learn every edge case, every hard-won fix, and every weird business rule the current system already handles. That accumulated knowledge is most of the value, and a rewrite throws it away on day one.
Questions that point toward refactor
You can almost always evolve rather than replace when:
- The problems are concentrated in a few areas, not everywhere.
- The system still ships value and isn’t actively on fire.
- The pain is “this is annoying to change,” not “this fundamentally cannot do what we need.”
- You can describe the specific improvements you’d make — which means you can make them incrementally.
Incremental refactoring keeps you shipping the whole time, de-risks each step, and lets you stop when you’ve got enough. It’s less heroic and almost always the better business decision.
Questions that point toward rewrite
A genuine rewrite is justified when:
- The core architecture cannot support where the business is going, and no amount of refactoring changes that (e.g., a fundamental data-model or platform constraint).
- The technology is a genuine dead end — unsupported, unhireable, or insecure at its foundation.
- The cost of change has grown so high that incremental progress has effectively stopped.
Even then, the smart version is rarely “stop everything and rebuild.” It’s the strangler pattern: build the new alongside the old, migrate piece by piece, and never have a big-bang cutover you can’t reverse.
The honest test
Ask the person advocating the rewrite two things: What specifically can’t this system do that the business needs? and Why can’t we get there incrementally? If the answers are concrete and architectural, listen. If the answers are really “the code is ugly and we’d rather start fresh,” you’re about to spend a year buying yourself the same product with newer bugs.
The reason this decision goes wrong so often is that the people making it are conflicted — the team that will do the rewrite wants to do the rewrite, and the vendor pitching it profits from it. It’s the textbook case for an outside opinion from someone with nothing to sell you either way.
If you’re facing a rewrite, a migration, or any hard-to-reverse technical bet, my architecture & second-opinion review gives you a clear, unbiased read — rewrite, migrate, or evolve — with the reasoning and a real path. Book a free intro call before you commit the year.