"We need to start again from scratch."
We hear this at least once a month. A company has an existing product that's slow, buggy, hard to maintain, or built on technology that's falling behind. Their instinct is to burn it down and rebuild.
Sometimes that's the right call. Often it isn't. The difference between the two matters enormously -- and most agencies won't tell you which one you're looking at because a rebuild is a bigger contract.
When Rescue Makes Sense
If the core architecture is sound but the codebase is messy, rescue is almost always the better path. Bad code can be refactored. Missing tests can be written. Performance problems can be diagnosed and fixed. These are engineering problems with engineering solutions.
Rescue also makes sense when the product has real users who depend on it. A rebuild means months of parallel development, a risky migration, and the near certainty that some functionality will be lost or broken in the transition. If your users are happy with what the product does -- just not how it does it -- rescue protects that value.
The strongest argument for rescue is speed. You can start improving the existing product immediately. A rebuild means months before you're back to where you already are, and during that time, the old product still needs maintaining. You're paying for two systems at once.
When Rebuild Is the Answer
If the architecture itself is wrong -- not just messy, but fundamentally unsuited to what the product needs to become -- rescue is putting lipstick on a structural problem. No amount of refactoring will fix a monolith that needs to be event driven, or a single tenant system that needs to serve multiple organizations.
Rebuild also makes sense when the technology is genuinely end of life. If your product runs on a framework that's no longer maintained, with dependencies that have known security vulnerabilities and no patches available, the risk of staying put eventually outweighs the cost of starting fresh.
And sometimes the honest answer is that the existing codebase is so deeply compromised -- no tests, no documentation, no separation of concerns, spaghetti logic throughout -- that the cost of understanding it exceeds the cost of replacing it. This is rarer than people think, but it does happen.
How We Decide
We start with an audit. Not a cursory glance -- a proper, structured review of the codebase, the architecture, the deployment pipeline, the test coverage, and the dependency health. This takes a few days, not a few hours.
We score the system across five dimensions: maintainability, security, performance, scalability, and developer experience. Each dimension gets a rating and a realistic estimate of what it would cost to bring it to an acceptable standard.
Then we compare that total rescue cost against a rebuild estimate. If rescue costs 60% or more of a rebuild, we typically recommend rebuilding -- because you get a modern, clean foundation as a bonus. Below that threshold, rescue is usually the smarter investment.
The Third Option Nobody Mentions
Sometimes the answer is neither. Sometimes the product doesn't need saving or replacing -- it needs retiring. If the market has moved on, if the users have found alternatives, if the business case no longer holds, the most expensive thing you can do is keep investing in something that shouldn't exist anymore.
We'll tell you that too. It's not what anyone wants to hear, but it's better than spending six figures to rebuild something nobody needs.
The Point
"Rebuild or rescue" is not a binary. It's a spectrum, and the right answer depends on specifics that can only be determined by actually looking at the code, talking to the users, and understanding the business.
Anyone who gives you an answer before doing that work is guessing. Or selling.