How this usually starts
The replies get slower, then they stop. The freelancer who was "nearly done" hasn't answered in three weeks. The agency's homepage now says it has ceased trading. The offshore team went quiet the day after the last invoice cleared. However it happened, you're left with a half-built website or app, a folder of receipts, and nobody picking up the phone.
We get a version of this call most months. The people who ring are rarely at fault. They hired someone who seemed capable, paid on time, and got left holding something they can't see inside. Recovery follows a fairly predictable order, and most of these projects turn out to be in better shape than they feel in that first week.
Send one last message, then stop chasing
The instinct is to keep emailing. Send one final, dated message asking for handover of all accounts and code by a specific day. Then stop waiting on it and move to the part you control: working out what you own and locking it down before something lapses, gets billed to a dead card, or stays in someone else's name.
Every item below is a place where a departed developer can still hold your business up without even meaning to.
- Domain registrar. Look your domain up on a WHOIS service, or the auDA registry for .com.au names. If the registrant is the developer, get it transferred into an account you control now.
- DNS. Often a different service from the registrar. Whoever controls DNS can take your website and your email offline. Make sure you have a login.
- Hosting. Work out where the site runs. Bank statements help, or a technical friend can trace it from the DNS records. If it's in the developer's account, you need to move before their billing fails.
- Source code. Ask for the repository on GitHub, GitLab or wherever it lives, transferred to an organisation you own. Code that exists only on someone's laptop is code you don't have.
- App store accounts. Apple Developer and Google Play accounts need to be in your business's name. Apps published under a developer's personal account are painful to move.
- CMS and admin logins. Confirm you have an administrator account, not just an editor one, and that the developer's account can be removed.
- Analytics, tag manager and search console. These hold your history. If they were set up under the developer's Google account, get ownership added to yours.
- Payment gateway. Stripe, Square, Tyro, PayPal. Money should only ever settle into an account in your name. Check who owns it.
- Everything else with a login. Transactional email, SMS, maps, booking tools, marketing platforms. List them all.
Change every password you can and turn on two-factor authentication where it exists. Put every renewal date you find in the calendar. This takes an afternoon, and by the end of it you have a project instead of a crisis.
If something critical is in the developer's name and they won't cooperate, don't get into a threatening email exchange. Go to the platform directly. Registrars, hosting providers and app stores all have ownership dispute processes, and a business registration plus paid invoices carries a lot of weight.
Find out what you're holding
Now you have the keys. The next question is what's behind the door, and you can't tell from the outside. A site that looks nearly finished can be a shell with nothing behind it. An app that runs on the developer's phone can be a prototype that has never been deployed anywhere.
This is where an independent assessment earns its keep. You want someone with no stake in the outcome to look at the code, the hosting, the database and the accounts, and tell you in plain language what's there.
A proper assessment answers a short list of questions. Does the code match what was invoiced? Does it run in an environment you control, or only on the missing person's machine? Is it built on something another developer will be able to maintain? Are there licences, subscriptions or third-party services that will break the moment a payment lapses? What would it take to finish, and what would it take to make it safe?
Be wary of anyone who answers all that on a phone call without looking. Be just as wary of anyone who says "it all needs rebuilding" before they've opened the repository. We've written about the kinds of hidden liabilities that turn up in these reviews in our post on what technical debt means for owners, and the same applies here: the visible surface tells you very little about what it costs to keep.
A written assessment is also useful if there's a dispute over money. A document from a third party stating what was delivered against what was billed is worth more than a stack of angry emails.
Decide whether to continue, patch or start again
With the assessment in hand, there are three ways forward, and the assessment usually makes the right one obvious.
Sometimes you can pick up where it stopped. The code is sound, the platform is sensible, and the remaining work is well defined. A new developer onboards, finishes and ships. This happens more often than the weeks of silence would suggest.
Sometimes it's a partial rebuild. Parts of it are good. Other parts were built in a hurry, or by someone learning on your budget, and will cost more to fix than to redo. You keep the solid pieces and replace the weak ones.
And sometimes you start over, because the foundations are wrong, the platform is dead, or what exists is so far from what was promised that continuing means paying twice for the same result. It's painful, but it is a decision about the money you have left, not a verdict on the money already spent.
Sunk cost is what distorts this choice. You've paid for something, and walking away feels like admitting it was wasted. It bought you a clear picture of what you need, which is more than most first projects deliver. The only money you can still lose is the money you spend from here, so make the decision on that basis.
People also apologise to us for having been taken in. There's no need. Judging a developer's competence from the outside is hard, which is why owners hire developers in the first place.
Whichever path you take, get a clear scope for the remaining work before anyone starts. The process in what a discovery phase should deliver applies to a rescue as much as a fresh build, and it's shorter, because half the answers already exist.
Stopping it happening twice
Once things are moving again, a few habits stop this from being a repeat performance. None of them need technical knowledge, only insistence.
Put ownership in the contract. Every account, domain, repository and deployed environment belongs to your business from day one, in writing, and the intellectual property in the code transfers to you on payment. If a developer resists that, it tells you something.
Get owner-level logins to every account in the first week, even if you never use them. Handover at the end should be a formality because there's nothing left to hand over.
Insist on regular deploys to hosting you control. Work that only exists on a developer's machine is work you haven't received. Seeing the site or app running on your own environment every couple of weeks is the best early warning there is.
Keep a shared record of what's been agreed, delivered and paid. If someone disappears, that record is your recovery plan.
If you're looking at a stalled project right now and want a straight answer about what's there and what it will take to finish, we do this regularly and the first conversation costs nothing. We can assess what you have, take over the build, or put it on a proper support footing so it's never in one person's hands again. Get in touch and tell us where it stopped.
