A rescue isn't a rewrite by default. Putti, an Auckland team that has rescued more than 20 stalled projects for New Zealand businesses, keeps what's valuable and fixes what's broken. It runs in four stages, and here's what each one involves in practice.
What happens in the assessment?
Before anyone touches the code, an incoming team works out what's salvageable and what isn't. We start by recovering access to the repository, the hosting, the domain and the app store accounts. Then a senior engineer reads the codebase, checks the architecture against what the product has to do, and tries the features the status reports called done.
You get a straight picture of the state of things, often for the first time. That includes the call the whole rescue hangs on: whether the foundations can carry the product, or whether a rebuild is the honest answer. An independent code review is the fastest way to get there, and the first two weeks of most rescues go on this stage.
What does stabilising mean?
Stop the bleeding first. That means fixing the critical bugs, security holes and broken builds that put the project at immediate risk, so the ground stops shifting before any new work begins.
The order matters. Anything that loses data comes first, then anything that's a security hole, then crashes, then anything that stops money moving. It usually takes two to six weeks, and it's the point where the app stops being a liability and becomes something you can demo again.
How do you re-plan a project that's already late?
From the real state of the code, not the original optimistic plan. With a stable base and a clear assessment, the scope, the sequence and the timeline all get estimated again. The new estimate comes from what the audit found, not from the proposal that started the whole thing.
You'll see named people, milestones you can click through and a clear line between what's finished and what's still ahead. This is the step where a rescue stops feeling like firefighting and starts feeling like a project again.
How is the work delivered?
In short, visible increments, so you can see progress and rebuild confidence. Each increment is something you can open and use, not a line in a status report. Most rescues Putti runs finish in 4 to 12 weeks from the day we get access.
We've rescued more than 20 projects other teams couldn't finish, and Putti's approach to project rescue is the same every time. If you're still deciding what to do first, our playbook for a failing software project covers the first week, and what a rescue costs compared with starting over covers the money.
Tell us what's happening and we'll tell you whether it's a rescue or a rebuild.
Last updated: November 2, 2026
Frequently asked questions
-
How long does a software project 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. Fixing the critical problems usually takes two to six weeks after that. The remaining scope is estimated from the audit rather than the original proposal, which is why the range is wide.
-
What do you need from me to start a rescue?
Access to everything the project depends on. That means the source code with its history, the hosting and domain logins, the app store accounts, the database and whatever documentation exists. If the developer still has some of it, we'll help you get it back. Nothing starts until you hold the keys, because without them you're negotiating from the weaker side.
-
Will you rewrite my whole application?
No, not by default. A rescue keeps what's valuable and fixes what's broken, so most of the code that works stays put. We only recommend a rebuild when the audit shows the architecture can't carry the product or there's no source code to recover. You get that recommendation in writing, with the reasons, before any rebuild work starts.
-
What gets fixed first in a rescue?
Whatever would hurt you in front of a customer, in a set order. Anything that loses data comes first, then security holes, then crashes, then anything that stops money moving. Until that ground stops shifting, new features would only be built on top of problems. It's the stage where an app goes from a liability to something you can demo again.
-
Can I still use my original developer during a rescue?
Sometimes, but we'd advise caution until you hold the code and accounts. The rescue team needs full access and a plain account of the project's history. If the original developer is cooperative, their knowledge speeds things up. If they've gone quiet, our guide on what to do when your developer disappears covers the first steps.
-
Do you stay on the project after the rescue?
Yes, if you want us to. Once the product is stable and delivered, we can carry on with maintenance and new features, or hand over clean documentation to your own team. Either way, the senior engineers who audited your project are the same people who fixed it, and we never outsource or subcontract the work.