If your developer has disappeared, work in this order: send one clear written message with a deadline, lock down every account you can still log into, list everything the project depends on and who controls it, then recover the pieces in order of damage: domain first, then code, then hosting and data, then app store listings. Most of it is recoverable. The parts that are not are the ones held only in their name.
The instinct is to panic, post about it, and start again with someone new. Do none of those yet. Plenty of disappearances turn out to be illness, burnout or a family emergency, and the rest are best handled calmly and in writing anyway.
Step 0: one message, in writing, with a date
Before anything else, send a single message through every channel you have: email, the platform you met on, the chat app you used. Keep it short and neutral. You are not accusing anyone. You are creating a clear record and giving them an easy way back.
Hi Sam, I have not heard from you since the 3rd and I hope everything is all right. I need to keep the project moving, so by Friday the 18th I need either a short update from you, or the following handed over: admin access to the repository, the hosting login, and the app signing details. If I do not hear back by then I will start moving things to another developer. Thanks.
Then wait until the date. In the meantime, do the steps below that do not depend on them.
Step 1: lock down what you can still reach
Some of the accounts will already be yours. Secure those first, today:
- Change passwords on every account you own that they might know, and turn on two-factor login where it is off.
- Remove or downgrade their access in accounts where they are an invited user: your code host, hosting, analytics, app store accounts.
- Rotate API keys they had: payments, email sending, maps, AI services. A secret key sitting on a laptop you cannot see is a key you should replace.
- Check every bill. Find out which services are paid on their card. When they stop paying, those services stop, and a lapsed database is far worse than a lapsed subscription.
Step 2: make an inventory
You cannot recover what you have not listed. Spend an hour on a table like this one:
| Piece | Where it lives | Whose account | How urgent |
|---|---|---|---|
| Domain name | The registrar | ? | Highest: controls the site and email |
| DNS | Registrar or a DNS provider | ? | High |
| Source code | Code host | ? | High |
| Hosting and database | Cloud provider | ? | High: holds your users' data |
| Email sending, payments, other APIs | Each provider | ? | Medium |
| App store listings | Apple and Google developer accounts | ? | Medium, but slow to fix |
| Signing keys, certificates | Often a laptop | ? | Ask early |
| Designs, documents | Figma, Drive | ? | Low |
Every row where the answer is "theirs" is a row you need them for, or a row you will rebuild. Knowing which is which tells you how bad things really are.
Step 3: the domain
The domain comes first because it controls everything else: the website, the email, the login links, the password resets.
If it is registered in your own account at the registrar, you are fine. Point it wherever you need it.
If it is registered in their name, the registrar will normally only deal with the registrant on record. That means you need them to transfer it, or you need a formal route, and the formal route depends on the registrar, the country and what you can prove. Gather your evidence now: invoices that mention the domain, messages agreeing it is yours, payments you made for it. Then check the expiry date with a public domain lookup, so you know how much time you have.
Step 4: the code
If the repository is in your organisation, clone a full copy today and keep it somewhere they cannot reach. That copy is the project.
If it is in their personal account, you need them. Ask specifically for the repository to be transferred or for you to be made an owner, not for "the files", because the history matters to whoever picks it up next.
If nobody can produce the code, check what is running. A live website or app is not the source code, but a new developer can sometimes recover parts of the front end from it, and the hosting provider may hold the deployed build. It is a salvage job, not a recovery, and it is expensive.
Step 5: hosting, data and services
If you can log into the hosting account, take a full database backup before you change anything else. Then confirm who pays the bill and move it to your card.
If you cannot log in and the account is in their name, contact the provider's support with your evidence and be specific about what you need. Some providers will help a business show it owns the service; many will not hand over another customer's account. Either way, the user data inside is the thing you cannot recreate, so put this ahead of the code if the code is safe in your hands.
Step 6: app store listings
This is where "in their account" hurts most, because both stores built their transfer process around the original owner taking part.
- Apple: the account holder of the sending account starts an app transfer, and the account holder of the receiving account accepts it. The app keeps its reviews, ratings and bundle ID. (Apple's app transfer overview)
- Google Play: the original account submits a transfer request to the target account, which needs its own registration transaction ID, and Google reviews the request. (Google's app transfer guide)
Both were checked in October 2026. Without the original owner, you are usually looking at publishing a new listing under your own account, which starts again with no reviews and no download history. That is survivable for a new app and painful for an established one.
Step 7: bring in someone new, carefully
When you hire the next person, do not start with features. Start with a short, paid audit: what is there, what state it is in, what is missing, what it would take to run it safely. A week of someone reading the code saves a month of guessing.
Expect the estimate to be higher than a fresh build would suggest. The project cost estimator adds a quarter on top for "an existing codebase to extend", because reading someone else's code is real work and nobody knows what is in it until they look. How to hire a developer to fix an existing app covers what to ask for.
Making sure it never happens twice
Almost every painful recovery has the same cause: something important was set up in the developer's account "for now". The fix costs nothing and has to happen on day one.
Create the domain, the code host, the hosting, the database and both store accounts in your own name, and invite the developer in. Get ownership of the code in writing, as covered in who owns the code. Then, if someone disappears again, the worst case is finding a new developer, not finding your own product.