It happens more often than anyone admits. The freelancer who built your app stops replying on WhatsApp. The small agency’s website goes offline. The one developer who understood your system takes a new job and moves on. Meanwhile customers are still logging in and orders are still coming through. Here is the plan we follow when a business comes to us in exactly this position.
Steps 1 and 2: stop the bleeding
1. Make a list of what is live
Before you change anything, write down every piece of the system you know about: the website, the mobile apps, the admin panel, the domain, email, any payment gateway and any integrations with accounting or delivery partners. Note what is working today. This list becomes your map, and it stops a recovery turning into a guessing game.
It is also worth one last, formal attempt at contact. Send a polite email, not just a chat message, asking for account access, the latest code and any outstanding documentation by a clear date. Many disappearances turn out to be illness, burnout or a business that quietly closed, and a calm request often gets a better answer than an angry one.
2. Take control of every account
Access is the most urgent thing. If your developer registered accounts in their own name, you need to move them into yours, starting with the ones that could take your business offline. Most providers have a recovery process for legitimate owners, especially if invoices or a trade licence prove the account belongs to your company.
- Domain registrar and DNS — whoever controls these controls your website and email.
- Hosting and cloud such as AWS, Azure, DigitalOcean or a cPanel host, including the root or owner login.
- App store accounts for Apple and Google Play, ideally registered to your company.
- Code repository on GitHub, GitLab or Bitbucket.
- Third-party services like payment gateways, SMS providers, Firebase and email delivery.
Once you are in, change passwords, turn on two-factor authentication, remove access for anyone who should no longer have it and keep the new credentials in a shared password manager that your company owns. This is also the moment to switch on automatic backups if none exist.
Domains deserve special care. A .ae domain is managed under the TDRA through accredited registrars, and recovering one usually means showing your trade licence and proof that the domain was registered for your business. Start that process early, because transfers can take several days and your email depends on it too.
Steps 3 and 4: get your code back
3. Recover the real source code
Having a repository is not the same as having the code that is running. We regularly find repositories that are months behind the live server, because changes were made directly in production. Download a full copy of the server files and database, compare them with the repository, and treat the live version as the truth until proven otherwise.
Mobile apps add one more trap: signing keys. Updates to an Android app must be signed with the right key, and iOS releases need certificates under your Apple developer account. If the developer held the only copy of an Android keystore, recovery depends on whether Play App Signing was enabled. Check this early, because it can decide whether you update the existing app or publish a new listing.
Check your contract too. In the UAE, as in most places, intellectual property doesn’t automatically pass to the client unless the agreement says so. If yours is vague, get legal advice on securing a written assignment. It matters later when you raise investment or sell the business.
4. Write down how it works
Next, create the documentation that should have existed. Which languages and frameworks are used, where it is hosted, how a new version gets deployed, which scheduled jobs run overnight and which outside services it calls. Even rough notes cut the time a new team needs to get productive from weeks to days.
Include a simple diagram if you can, even a photo of a whiteboard sketch. Seeing the website, mobile apps, database, payment gateway and email service connected on one page helps everyone, from your accountant to your next developer, understand what depends on what.
You don’t own your software until you own the accounts, the code and the knowledge of how it runs.
Steps 5 and 6: understand and stabilise
5. Get an independent code audit
Ask an experienced team to review the code, infrastructure and security. A good audit takes one to two weeks for a typical business app and usually costs in the range of USD 2,000 to 6,000. It should tell you how healthy the code is, what is risky, what is missing and roughly what each fix would cost, in language a non-technical owner can follow.
6. Fix the urgent risks first
Resist the temptation to start new features straight away. First patch critical security issues, update anything badly out of date, add uptime and error monitoring, and confirm you can deploy a small change safely. Only when you can release a one-line fix without fear is the system really back under your control.
Keep people informed while this happens. Your staff and key customers don’t need technical detail, but they should know that the system is being looked after and who to contact if something breaks. A short, honest update builds far more confidence than silence, especially if a few features are paused while the urgent fixes go in.
Step 7: decide what comes next
With the audit in hand, you can make a calm decision instead of a frightened one. Rebuilding everything feels clean, but it is slow and expensive and carries its own risks. In our experience, most inherited systems are worth keeping and improving. The table below shows the pattern we usually follow.
Whatever you decide, choose your next partner carefully. Ask whether they have taken over existing codebases before, not just built new ones, and how they price the first few weeks of discovery. A team used to takeovers will usually suggest a short paid stabilisation phase before committing to a long roadmap, which is exactly what you want.
Making sure it never happens again
The best protection is boring paperwork and good habits, agreed before any work starts. Whoever you work with next, freelancer or agency, make sure these basics are in place from day one rather than added after something has already gone wrong:
- Every account registered to your company email, with you as owner and the developer as a user.
- A contract with a clear IP assignment and a handover clause.
- Code pushed to your repository at least weekly, with deployments from that repository only.
- A short, living document explaining how the system is built and deployed.
The bottom line
A disappearing developer is stressful, but it is rarely the end of your product. Take back the accounts, find the real code, document what exists, get an honest audit and stabilise before you build anything new. Then put contracts and habits in place so that the next time someone moves on, it is a handover rather than an emergency.
