When we take over an app from another developer, we don't add features or refactor anything for the first 48 hours. We don't change anything until we know what we could lose.
This is the checklist we run. You can use it yourself if you've inherited a product, if your developer is leaving, or if you're starting something new and want to avoid these problems from the beginning.
Hours 0 to 12: get the keys
Most takeover problems are ownership problems. A founder can be paying for everything and still control very little of it.
- Apple Developer and Google Play: who is the account holder? If it's the old developer, moving the app takes time and needs their cooperation, so start now.
- Domain and DNS: whose registrar account is it, whose card pays for it, and when does it renew?
- Cloud accounts: who has the root login, and whose card is on file?
- Code: get the full repository with its history, not a zip file. History tells you why things were done, and a zip tells you nothing.
- Third-party services: list everything the app depends on, such as payments, email, push notifications, maps and analytics, along with who owns each account.
Hours 12 to 24: prove you can ship
Until you've released a build yourself, you don't really control the product. So test that before you need it.
- Build it on a clean machine. This shows up the undocumented setup steps and the files that only exist on one person's laptop.
- Find the signing certificates and profiles. Check when they expire, and for Android, make sure you have the upload key.
- Push a no-change build to TestFlight and Play internal testing. If that works, you can ship a fix on the day you need one.
- Check how the backend gets deployed. Is it a pipeline, or one person running commands on a server?
Hours 24 to 36: check what could hurt
- Backups: restore one to a separate environment. Until you've done that, you don't know you have a backup.
- Secrets: look for API keys and passwords hardcoded in the app or the repository. Anything shipped inside a mobile app should be treated as public.
- Access: list who can still get in, including former developers, agencies and old contractors. Remove anyone who shouldn't be there and rotate the credentials they had, but check first what will break.
- Dependencies: look for frameworks and runtimes past end of life, and for store deadlines that could block your next release.
Hours 36 to 48: find the hidden parts
- Scheduled jobs: cron jobs and background tasks are often documented nowhere, and you only find out about them when they stop.
- Manual steps: ask what someone does by hand before each release or at the end of each month.
- Renewals: domains, certificates and third-party subscriptions that nobody is watching.
- Crash logs and store reviews: these tell you what users are running into today, which isn't always what the backlog says.
What you should have at the end
One page, written for the founder and not for engineers, with three lists: what's at risk, what to fix first, and what can wait. Feature work starts after that.
If your developer is still replying, start today
Ask for the access list while the relationship is still working. Getting an account holder changed is much easier with the current holder's help than without it.
Starting a new app? Use the same list on day one
Everything above is cheap to set up properly at the start. Open the store accounts, the domain and the cloud in your own company's name, keep the code in a repository you own, automate your releases, and test a backup restore before you launch. Whoever builds your product, you'll keep control of it.
We build new products and take over and run existing ones, across mobile apps and backends. If you're planning something new, or you've inherited something and aren't sure what state it's in, we'd be glad to take a look.