Guide · Taking over a project
Your developer disappeared: a 10-step recovery checklist
By MervenorPublished Last reviewed 3 min read
If your developer or agency has gone, recover access before you change anything. Get the domain, the hosting, the code and the accounts into your name, in that order, and then change every password and key the previous developer knew. Only then decide what to fix, with an independent review of what you have.
Before you start
When the developer or agency who built your application goes quiet, the instinct is to hire someone to fix the code. Start one step earlier: the code is only useful once you control everything around it — the domain, the hosting, the repository, the secrets and the services it depends on.
The 10 steps
Do not change anything yet
Write down what you know: the address of the app, who used to work on it, and which emails and invoices mention its services. Changes made in a hurry are the hardest to undo.
Find the domain
Look up who the domain is registered to and at which registrar. If it is not in your company's name, ask for it to be transferred first: whoever holds the domain controls your website and your email.
Get the hosting account
Find where the app runs and whose card pays for it. Ask for the account to be transferred to you, or for you to be added as an owner.
Get the code
Ask for the source code repository to be transferred to an account you own. If it cannot be found, part of it can be rebuilt from what is deployed (see below).
Collect the secrets
Passwords, API keys, database credentials and environment settings. Keep them in a password manager your company controls.
List every third-party service
Email sending, payments, analytics, maps, app stores, error tracking. For each one: who owns the account, who pays, and what breaks if it stops.
Change the keys the previous developer knew
Once you hold them, change the passwords and API keys, starting with payments, email and the database. Plan a quiet window: some changes need a release.
Check the backups
Find out whether the database is backed up, where, and when the last backup ran. Then restore one to a test environment to prove it works.
Find out how it is built and released
Can the app be built from a clean machine? Where do releases run from? If nobody knows, that is the first thing to fix.
Get an independent review before new work
Before anyone adds features, have the codebase reviewed: what is risky, what is out of date, and what it will cost to make it safe.
If the code is missing
Part of an application can often be rebuilt from what is deployed: the running site, build artefacts, the database schema and the hosting configuration. It is slower than recovering the repository and never complete, so ask for the repository first, in writing.
When to bring in help
Bring someone in once you have the accounts, or as soon as you are stuck on one. A good first engagement is read-only: a review of what you have and a plan, before anyone changes it.
Perlustra, the codebase health audit, is the next step: five business days, at a fixed fee.