Yes. Putti, an Auckland software team, takes over stalled, offshore and vibe-coded projects for New Zealand businesses, and it's work we do routinely. We've rescued more than 20 projects other teams couldn't finish. Picking up someone else's unfinished build is one of the hardest jobs in software, so here's how we handle it.
What kinds of project do you take over?
Three kinds, mostly. Offshore or freelance builds that stalled, drifted or lost their team. In-house projects that ran out of capacity or momentum, often because the one person who understood the code moved on. And vibe-coded apps, generated with tools like Cursor, Bolt, Lovable or GitHub Copilot, that look right in a demo and break under real conditions.
The cause is different each time. The first move is the same.
What do you need to get started?
Access to everything the project depends on. That's the source code with its full history, the hosting and domain logins, the app store accounts, the database and whatever documentation exists. Until you hold those, you're negotiating from the weaker side, and so is any team trying to help you. It's also worth checking that your contract assigns the code to you in writing.
What happens after we take it over?
An audit first. A senior engineer reviews the codebase, the architecture and what's actually working, and you get a plain picture of the state of things. Then we stabilise: fix the critical issues and get a working baseline. Then we finish the build to a production-ready standard.
Most rescues run 4 to 12 weeks depending on scope, and the first two weeks usually go on recovering accounts and reading the code. How a software project rescue actually works walks through each stage.
What if the original developer has gone quiet?
It happens a lot, and it's recoverable. We've written a separate guide on what to do when your developer disappears, and the short version is to work out what you can recover through the accounts you already hold before anyone asks the developer for anything.
Why does it get cheaper to fix the sooner you look?
Because every month a failing project runs adds code nobody understands and decisions nobody wrote down. Stabilising a build at the first warning sign costs far less than salvaging one that's collapsed. If you're not sure yours has reached that point, our rescue playbook lists the signs, and what a rescue costs compared with starting over explains how the decision gets made.
Last updated: November 2, 2026
Frequently asked questions
-
Can you take over a project that has no documentation?
Yes, and it's more common than you'd think. We start by reading the code and working out how it behaves, then write down what we find so the next person isn't in the same position. Missing documentation slows the first two weeks. It rarely stops a rescue, and it's part of what we fix before the project moves on.
-
Do you need the original developer's help to take over?
It helps, but it's not required. What we need is access: the source code, the hosting and domain logins, the app store accounts and the database. If the original developer still holds some of those, we'll help you get them back. Their cooperation speeds things up, and a handover call is worth asking for.
-
Can you take over an app built by an offshore team?
Yes. Offshore builds often stall over time zones, unclear scope or a team that rotated. The code is usually workable even when the process wasn't. We audit what's there, keep what holds up and fix the rest. The people reviewing it are Putti employees, and we never subcontract the work.
-
Can you finish a vibe-coded app?
Yes. Apps built with Cursor, Bolt, Lovable or GitHub Copilot often look finished and then break under real users. We check security, data handling and structure first, because that's where the gaps hide. Some prototypes only need hardening. A few need rebuilding, and we'll tell you which one you have after the audit.
-
How long does it take to take over a stalled project?
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 after that. The rest is estimated from the audit, not the original proposal.
-
Will I own the code after you take over?
Your code should live in a repository you own, with its full history, and the accounts should be in your name. That's the first thing we check. If ownership is unclear, we'll say so before any work starts, because it's far easier to fix at the beginning than halfway through a rescue.