If your software project is failing, do one thing before anything else. Stop, and get an independent audit of the code and the delivery. Do it before you fire the developers and before you throw the code out. Most of the money lost in a failing build is lost in the panic. Putti has rescued 20+ projects in New Zealand.
Is my project failing, or just late?
Late is normal. Software slips. Failing is different, and the difference is that nobody can tell you when it'll be done or why it isn't.
Here are the ten signs we see most often. The launch date has moved three times and the reasons keep changing. Every change request comes back priced as a variation. Demos get rescheduled the day before. Bugs you reported as fixed come back a fortnight later. The invoices grow faster than the list of working features. Progress reports describe activity but never something you can click. The team has gone quiet in the week before a milestone. You've never seen the source code, or you don't know where it lives. Someone senior on the vendor side has stopped turning up to calls. And your own team has quietly started building workarounds in spreadsheets.
Three or more of those at the same time is failing. One or two is a hard conversation. That's the whole test, and we've never found a fancier one that worked better.
What's the first thing to do?
Stop. Not cancel, not pause the contract, just stop making new decisions for a week.
The instinct when a build is going wrong is to do something big. Add developers. Switch agencies. Start again with a cleaner team. Every one of those is a six-figure decision made with no information, because at this point you don't actually know what's wrong. You know the symptoms. You've been told a story about the causes, by the people who have the strongest reason to shape that story.
So the first real move is an independent audit. A senior engineer who has no stake in the outcome reads the code, checks the architecture against what the product needs to do, runs whatever tests exist, and tries the features the status reports called done. A week or two is usually enough. The output is a plain document: what works, what's broken, what's missing, and whether the foundations can carry the product.
That document is what every other decision hangs off. Before it, you're guessing. After it, you're choosing.
How does a rescue actually run?
Once the audit is in your hands, the rest follows a pattern. We've run it more than 20 times and it hasn't changed much.
The first step you've already done: stop and assess. The second is the audit itself, and the one thing to insist on is that you get the written report whether or not you go ahead with the same team. It's yours.
Third is stabilising. This means fixing the things that would embarrass you in front of a customer, in order: anything that loses data, anything that's a security hole, anything that crashes, anything that stops money moving. Two to six weeks, typically. It's the point where the app goes from a liability to something you can demo again.
Fourth is the decision the audit was for. Rescue or rebuild. Rescue when the foundations hold and the gaps are the usual ones, no tests, no documentation, features that only work on the happy path. Rebuild when the architecture can't carry the product, or when there's no source code to be had. In our experience the first is far more common than people fear, and the second is far more common than vendors admit.
Fifth is the takeover plan. The remaining scope gets estimated properly this time, from the audit rather than from the original proposal, with milestones you can see and a team you can name. That's the point at which it stops being a rescue and starts being a project again.
What should I not do?
Four things. We've watched each of them turn a bad quarter into a bad year.
Don't rebuild in a panic. A rebuild feels clean and it feels like control. It's also the single most expensive thing you can do, and it throws away the parts of the old build that were working, which is usually most of them.
Don't add people to the team that's already late. More developers on a project that has no tests and no documentation means more people reading the same undocumented code, and the original team's velocity drops while they explain it. It's the oldest finding in software management and it's still true.
Don't fire the developer before you hold the code. Get the repository with its full history, the hosting and domain logins, the app store accounts and the database in your own hands first. A developer who feels a dispute coming can lock you out in an afternoon. Then have the conversation.
Don't pay the next milestone until somebody independent has verified it. "Done" in a status report and "done" in a browser are different things, and the gap between them is where the money goes.
Why call Putti for a rescue?
Because this is most of what we do. Putti has rescued more than 20 stalled or failing projects since 2010, across mobile apps, web platforms and AI systems, and hasn't lost one. Across 100+ projects our record is zero failures.
Two things make that work. The senior engineers who audit your project in the first fortnight are the same people who fix it, so nothing gets lost in a handover. And we build in Takapuna, Auckland, not offshore, so the person you call is the person writing the code. The rescue for Hydraulink is one example among many, and we're happy to walk you through others.
Where to start
If your project matches three or more of the signs above, talk to us about a rescue assessment this week rather than next. It's a short, fixed-price piece of work and you keep the report either way.
If you'd rather read first, start with how a project rescue actually works and what a rescue costs compared with starting over. And if your developer has gone quiet altogether, what to do when your developer disappears covers the first 48 hours.