"Rescue or rebuild" is the first real decision on a failing project, and the money follows it. The instinct is to assume you've got to start over. Don't make that call yet. You can't price either option until someone independent has looked at what you already have.
Is a rescue really cheaper than a rebuild?
Most of the time, yes, because a rescue keeps what already works. The screens that were signed off, the database that holds real customer records and the integrations that were painful to get running all stay. You pay to finish and fix the rest.
A rebuild throws all of that away and then repeats the discovery work that produced it. It also tends to repeat the mistakes that sank the first attempt, because the same brief is going to a new team.
| 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, because working parts are kept | Slower, because you start from zero |
| Best when | The foundation is salvageable and some features work | The code is unmaintainable, insecure or the wrong architecture |
| Main risk | Inheriting hidden debt | Repeating the mistakes that caused the first failure |
What decides whether it's a rescue or a rebuild?
Whether the foundations can carry the product. A build with no tests, no documentation and half-finished features is the usual picture, and it's fixable. A build whose architecture fights the thing it's supposed to do, or one where nobody can produce the source code, usually isn't.
Putti has rescued more than 20 stalled or failing projects since 2010. Far more of them were rescues than rebuilds. The audit is what tells you which one yours is, and it can go either way.
What pushes the cost of a rescue up or down?
How long it's drifted is the biggest one. A project that's been failing for three months is cheaper to save than one that's been failing for twelve, because every month adds code nobody understands and decisions nobody wrote down.
Lost knowledge is next. If the original developers have left, part of the budget goes on reading the code before anyone changes it. A column called notes2 that three people fill in differently takes real time to untangle.
The work still left to reach a stable release matters more than day rates. Our guide to what custom software costs in NZ covers the underlying ranges for that part.
Missing basics add to it too. No access to the repository, the hosting or the app store accounts means those get recovered first, and that's unglamorous work.
Why do we start with an audit instead of a quote?
Because a quote given blind is a guess, and you'd be the one carrying the risk of it. Our independent code review is a small, fixed-price piece of work. A senior engineer reads the code, checks the architecture against what the product has to do, and tries the features the status reports called done. A week or two is usually enough.
You get a plain document: what works, what's broken, what's missing, and whether the foundations hold. It's yours whether or not you carry on with us. After that, the rescue number comes from evidence, and you'll know it before you spend it.
What should you do before you ask for a quote?
Get the basics into your own hands. That's the repository with its full history, the hosting and domain logins, the app store accounts and the database. Don't pay the next milestone until somebody independent has verified the last one, and don't fire the developer before you hold the code.
The full order of play is in our rescue playbook for failing software projects, and how a rescue actually works walks through the stages once the audit is in.
If your build is in trouble, tell us what's happening and we'll give you a straight rescue-or-rebuild recommendation.
Last updated: November 2, 2026
Frequently asked questions
-
How much does it cost to rescue a failed software project?
There's no honest flat figure, because two projects with the same symptoms can sit in very different states. When the foundation is sound, a rescue normally costs a fraction of the original build, since the working parts stay. Putti starts with a small fixed-price audit, so you know the real number before you commit to anything larger.
-
Is it cheaper to rescue a project or start again?
Usually the rescue, as long as the architecture can carry the product. You keep the screens, data and decisions that already work, and you pay to finish the rest. A rebuild only wins when the code can't be maintained, there's no usable source, or patching would cost more than starting clean. The audit settles which one you have.
-
Why can't a rescue team quote before looking at the code?
Because the symptoms tell you very little. Late, buggy and over budget describe a sound build with a weak plan as well as a broken one. Any firm quote given blind is a guess, and you'd carry the risk of it. A short audit replaces the guess with evidence, and the written report is yours either way.
-
What makes a rescue more expensive?
Drift, lost knowledge and missing basics. Every month a failing project keeps running adds code nobody understands. If the original team has left, some of the budget goes into reading the code before changing it. No tests, no documentation or no access to the source and accounts push the cost up too. Acting early is the cheapest move.
-
When should I rebuild instead of rescue?
Rebuild when the architecture can't carry the product, when there's no source code to recover, or when the fixes would cost more than starting clean. Those cases are rarer than people fear and more common than vendors admit. We'd rather tell you straight after the audit than quietly patch something that won't hold.
-
How long does a rescue take?
Most rescues Putti runs take 4 to 12 weeks from getting access to a delivered product. The first two weeks go on recovering accounts and reading the code. Stabilising the critical problems usually takes two to six weeks. The rest is estimated from the audit rather than the original proposal, so the range is wide.