"Rescue or rebuild" is the first real decision for a failing project, and the money follows it. The wrong instinct is to assume you must start over. The right first step is a short, honest assessment of what you already have.
Rescue vs rebuild at a glance
| Rescue (fix and continue) | Rebuild (start over) | |
|---|---|---|
| Typical cost | A fraction of the original build when the core is sound | Similar to, or more than, the original build |
| Time to value | Faster, you keep working parts | Slower, you start from zero |
| Best when | Foundation is salvageable, some features work | Code is unmaintainable, insecure or the wrong architecture |
| Main risk | Inheriting hidden debt | Repeating the mistakes that caused the first failure |
What actually drives the cost
- How much is salvageable. Clean, tested code lowers the cost; an unmaintainable codebase raises it.
- How far it drifted. The longer a failing project runs, the more expensive the rescue, so acting early is the cheapest option.
- Scope from here. Rescue cost is driven by the work still left to reach a stable release, not by day rates. See how much custom software costs in NZ for the underlying ranges.
- Knowledge lost. If the original team left, some cost goes into understanding the code before changing it.
How we price it honestly
We start with an independent code review so the decision is based on evidence, not guesswork. That tells you what is salvageable, what a rescue would cost, and whether a rebuild is genuinely the better value. We have rescued 20+ projects other teams could not finish, with a zero-failure record.
If your build is in trouble, tell us what is happening and we will give you a straight rescue-or-rebuild recommendation.