Insights · 6 min read
Your app developer disappeared. Here's what to do next
By Austin Hunter ·
It happens more often than people admit. The freelancer takes a full-time job, the agency folds, or the friend who built it gets busy. The app keeps running for a while, until a store deadline, an expired card or a broken login turns it into an emergency. We've picked up products built by other teams, and the order below is the one that keeps the risk lowest.
1. Find out which accounts exist, and who owns them
Before anything else, make a list. The question for each one is the same: is it in your company's name, or the developer's?
- Apple Developer account and App Store Connect (iOS apps)
- Google Play Console (Android apps)
- The domain registrar and DNS
- Hosting and cloud accounts (for example Vercel, AWS, Google Cloud, Firebase, Hostinger)
- The code repository (GitHub, GitLab, Bitbucket)
- Payments (Stripe, RevenueCat) and email sending services
- Analytics, crash reporting and any paid APIs the app calls
Anything in your company's name is safe. Anything in the developer's personal name is the real risk, because if their card expires or they close the account, your app goes with it.
2. Move what you can into your own name
Apple and Google both have official ways to move an app from one developer account to another (App Transfer in App Store Connect, and an app transfer request in Play Console), so you don't lose your listing, reviews or users. Domains can be moved to a registrar account you control with a transfer code. Cloud and repository accounts usually let the current owner add you as an owner or admin. If the developer is reachable but slow, these are the few requests worth chasing, ideally in writing.
3. Get a copy of the code
Ask for repository access, not a zip file. A repository has the history, and the history shows what was changed recently and why. If all you can get is a zip, take it: a working copy is far better than none.
4. Check what's actually running
- Does the live app match the code you were given? (It often doesn't.)
- Are there store notices waiting, like a Google Play target-API deadline or an Apple SDK requirement?
- Are backups running, and has anyone ever restored one?
- Are passwords, API keys or secrets sitting in the code where they shouldn't be?
- What is each service costing per month, and is any of it unused?
5. Decide who takes it over
Whoever you hire next should start with a short, read-only review before changing anything, then tell you plainly what works, what's risky and what to fix first, with a fixed price for the fixes. Be wary of anyone who recommends a full rebuild before they've read the code. Sometimes a rebuild is right, but it should be a conclusion, not an opening line.
How we handle it
We took over BookReverb's existing codebase and now lead all of its development, and we run our own apps in both stores. If your developer has gone quiet, we can start with the review and then keep the app running on a monthly care plan, with every account kept in your name.