The call usually comes after the second missed launch date. The offshore team has gone quiet, or is asking for another payment before they'll hand over the code, and the app that was "90 percent done" in March still can't take a payment. You're not the first, and the situation is more fixable than it feels.
What do you need to get back from the offshore team first?
Nothing else matters until you've got the keys. Before you talk to a rescue team, get the source code repository with its full history, admin access to the hosting and the domain, the Apple and Google developer accounts, and the logins for every third-party service the app relies on: payments, email, maps, push notifications, analytics. Ask for the database and any environment configuration too.
Check the contract. If it says you own the code on payment, quote it back to them. If it doesn't say anything, ask for written confirmation that the IP transfers to you, and do it before the final invoice, because that's the only bargaining power you have left. We have seen builds where the developer held the domain and the App Store account in their own name, and unwinding that took longer than fixing the software.
How do you know what's worth keeping?
A short technical audit, usually a week or two, answers the only question that matters: how much of this is worth keeping? A senior engineer reads the codebase, checks the architecture against what the product needs to do, runs what tests exist (often none), and tries the features the status reports said were done.
The pattern we see most often in offshore builds isn't bad code. It's missing work dressed up as finished work. A login screen with no password reset. A "completed" payment flow that only works in sandbox. Credentials hard-coded into the source. No automated tests, so nobody knows what breaks when something changes. That's all fixable, and it's far cheaper than starting over.
The audit ends with a written picture of what works, what's broken, what's missing, and a recommendation: stabilise and continue, or rebuild the parts that can't be saved. You should get that document whether or not you go ahead with the same team, and it's yours to keep.
How long does it take to stabilise and finish?
Stabilising means fixing the things that would embarrass you in front of a customer: crashes, security holes, broken payments, data that doesn't save. That's typically two to six weeks of focused work and it's where the app goes from a liability to something you can demo.
Finishing the outstanding scope comes after, and it's estimated properly this time, from the audit rather than from the original proposal. Most rescues Putti runs in New Zealand land in the 4 to 12 week range end to end. We've turned around more than 20 stalled or failing projects since 2010 and haven't lost one.
Why did it go wrong, and how do you stop it happening again?
The problem with the offshore build was rarely that the developers were overseas. It's that there was a sales layer between you and the engineers, the team rotated without handover, and nobody was accountable in your time zone when the demo slipped. Those are structural problems and they'll happen with a local agency too if you let them.
The fix is to insist on the opposite structure: the people who scope the work are the people who build it, you can name them, and they're reachable during your working day. That's how Putti runs every rescue from Takapuna, Auckland, and it's why the second attempt tends to be the last one.
If your offshore build has stalled, the cheapest moment to look at it is now. Talk to us about a rescue, or read how a project rescue actually works first.
Frequently asked questions
-
Can an app built by an offshore team be fixed, or does it need a rebuild?
Most can be fixed. In our experience the code is usually workable and the real damage is in the gaps: no tests, no documentation, secrets hard-coded, and features that were reported as done but never finished. A rebuild only makes sense when the architecture can't carry the product, and a two-week audit tells you which case you're in.
-
What do I need to get back from the offshore developer before anyone can help?
The source code repository with full history, admin access to hosting and domains, the app store developer accounts, any third-party service accounts (payments, email, maps, analytics) and the database. If you don't have a written contract that says you own the code, get that clarified in writing before the last invoice is paid.
-
How long does it take to take over an offshore build?
Expect about a fortnight before any fixing starts, because access has to be recovered and the code audited first. Critical problems such as crashes, security holes and broken payments usually take two to six weeks after that. Finishing the scope comes last and is estimated from the audit, so the whole takeover typically lands between 4 and 12 weeks.
-
How much does it cost to fix an offshore-built app in NZ?
You'll know after the audit, which is a small fixed-price piece of work. Keeping what already works is why a rescue normally comes in well under what the original build cost. Only a broken foundation pushes the figure towards a rebuild, and the audit flags that early, before any larger commitment is on the table.
-
Will the same thing happen again with a New Zealand team?
It shouldn't, and the reason is structural rather than geographic. The failure mode with offshore builds is usually a sales layer between you and the engineers, rotating staff, and no one accountable in your time zone. Putti's rescues are run by the same senior Auckland team that scopes them, so the person you call is the person fixing it.