Your Developer Disappeared: What to Do in the First 72 Hours

• Silence isn't always abandonment. Spend the first day confirming what's happening, in writing.

• For several of your accounts, the only person who can hand over ownership is the person who's gone quiet. Calm is practical, not polite.

• Copy first, change later. Never lock someone out while they hold the only copy of something.

• Check whose card pays each bill and whose bank account receives your customers' payments.

• Ownership and contract questions go to a lawyer, not to a blog or a rescue agency.

• Get an independent review before you sign a rescue scope with anyone, including us.

Your developer hasn't replied in nine days, the launch was three weeks out, and you've just realised you're not sure where the code lives.

Search "developer disappeared" and most of what ranks is written by firms that sell rescues. The advice tends to run the same way: act now, lock everything down, grab the code, call us. Some of that is right. The order is wrong, and the order decides whether the next month is a handover or a fight.

Silence has more than one cause. A sole contractor can be ill or dealing with a family emergency. An agency can be in financial trouble, or losing the one person who knew your project. A dispute over an invoice can look exactly like ghosting from your side. Each needs a different response, and you can't tell them apart from your inbox.

If they've told you they're leaving rather than gone quiet, you have the better version of this problem. Skip the confirming and start on day two while they're still answering.

So the first job is to confirm. Send one calm written message to every channel you have: email, the project tool, text. Keep it short and easy to answer:

"We haven't heard from you since [date] and we need to plan around the project. Please reply by [day] with three things: whether you can still work on it, when we can expect the next update, and confirmation that we have admin access to the code repository and the accounts the product runs on. If something has happened, we'd rather know so we can work around it."

Then check what you can see without them. Has the agency's website or phone line changed? Are other clients saying the same thing? If you can open the code repository or the hosting dashboard, when did anything last change? Write every attempt and every finding in a dated log. You may need it later, and it keeps you honest about how long it's actually been.

The rescue playbooks treat speed as safety. For a lot of the accounts your product depends on, it isn't, because the one person who can hand them over is often the one who's gone quiet.

If your code sits in the developer's personal GitHub account, GitHub's documentation on personal repositories describes two permission levels: the owner and collaborators. Deleting the repository is an owner's action, not a collaborator's. If your app was published from the developer's own Apple developer membership, Apple's guidance on the Account Holder role says individual memberships change hands only in narrow cases, with Apple Developer Support involved. On an organization membership, the current Account Holder starts the transfer.

Payments follow the same pattern. Stripe's documentation on account roles says an account has only one Owner, and only the owner can transfer ownership.

Put those together and the case for staying calm is practical. An angry message, a public review or a revoked login can turn a cooperative exit into one where every transfer needs a lawyer. You can be firm in writing and still leave the door open.

The other way to make it worse is technical. Changing a password or key the live product uses can take the product down. And if the developer holds the only copy of something, locking them out locks you out too. Copy first. Change things later, deliberately, with someone who knows what depends on them.

Work through the accounts your product runs on. For each one, find out who owns it, whether you can get in with your own login, and whose card pays for it. A hosting bill on the developer's personal card is an outage waiting for an expiry date.

Where an account is already in the business's name, add a second administrator you control and turn on two-step sign-in. Where it isn't, ask for a transfer in writing and record the request in your log.

Read the contract, then decide whether you need a lawyer

Find the signed agreement and read what it says about who owns the work, what has been paid for, how either side ends the engagement and what happens at handover. If any of it is unclear, or the answer depends on what was or wasn't paid, that's a question for a lawyer. Not for a blog post, and not for the agency offering to rescue you. And don't hold back an invoice to apply pressure until someone qualified has read the contract with you.

Now separate what you were told from what you can open. Make two columns. On the left, what the last status update said was done. On the right, what you can reach yourself: a running product you can click through, a test build on your phone, a copy of the code, the design files, the scope you agreed and a list of the outside services the product uses.

The gap between the columns is the real size of your problem. It's often smaller than the panic suggests, and occasionally much bigger. Either way, it's the first thing any next team will ask for.

If the developer is reachable but leaving, this is also when a proper handover is still possible. The software project handover checklist has the full acceptance standard, including what changes when an exit is urgent. The handover readiness check turns the same questions into a record you can share with whoever comes next.

By the end of day three you should be able to choose one of three paths. Pick on evidence, not on how angry you are.

• Wait. They replied with a credible reason and a date, you hold a copy of the code, and you can get into every account the product needs. Agree the next checkpoint in writing and keep tidying your access in the background.

• Recover. They're reachable but leaving, or willing to cooperate with an exit. Plan a structured handover while they're still available, and expect to pay for their time to do it properly.

• Replace. They haven't answered after documented attempts, or what came back doesn't hold up. Secure everything you can, accept that some knowledge has gone, and plan for a new team needing time to learn the code before they can safely change it.

The instinct is to jump straight to replace. Recover is the better default whenever the developer can still be reached, because the cheapest documentation you'll ever get is the person who wrote the code, answering questions while they still will.

Once you start asking around, rescue offers arrive fast. Many will quote to finish the product or rebuild it, often from a demo and a conversation. Neither tells them what you actually have.

Before you sign a rescue scope with anyone, including us, have the existing work reviewed by someone whose findings another team could act on. The review should compare what was promised with what exists, say what's worth keeping, and recommend whether to continue, correct, re-scope or stop. That's how we run a software build second opinion: you get the evidence and the recommendation whether or not you hire us afterwards.

A rescue firm that wants to start rebuilding before anyone has looked at the code is selling certainty it doesn't have.

Today, do two things: send the message, and pull a copy of any code you can still reach. Everything else gets easier once those are done.