How to take over an app a freelancer left behind

List every place the app lives. The GitHub or Bitbucket repository, the cloud account, the domain registrar, the App Store and Play Console listings, the mail sender and Firebase each hide a separate login.

Ask the freelancer for a handover, even if the parting was awkward. Request a repository transfer rather than a zip file, so that the commit history survives. If they have gone silent, your contract and invoices are the evidence that the business owns the work, and a solicitor can use them.

Move each account to a company email address. A former contractor’s personal login can still deploy, delete or read customer data. That risk is live, and it is easy to close.

Bring in a senior engineer who did not write the app and ask for a plain written report, not a proposal. They should clone the code, run it on a clean machine, read the crontab and note every failure they meet. Nothing else counts yet.

The report should name the framework version, abandoned packages in package.json or composer.lock, secrets committed into the code, missing tests and whether the database has migrations. Check the live server against the repository. Freelancers often patch production by hand over SSH, and that edit then exists nowhere else.

Expect surprises. Many inherited apps run only on the original laptop, because the .env file, the Android signing keystore and the iOS provisioning profile were never saved anywhere else. Losing a keystore can block every future update of a published app.

Fix when the structure is sound and the faults are local. Rebuild when every change breaks something else, or when the framework is too old to patch, as with a Python 2 or AngularJS codebase. Rebuild too if nobody can explain the tables.

Retire the app when it no longer serves a real process. Plenty of inherited tools sit unused while people quietly work in spreadsheets and nobody remembers to switch the monthly hosting off. That is the cheapest outcome of all.

Distrust two instincts. One says everything must be rewritten because the code looks strange to you. The other says it works, so leave it alone. Both skip the evidence. A short stabilising phase often beats either.

Once you can run the app, document it while the knowledge is fresh. A short README inside the repository beats a long wiki that nobody updates, and it should say plainly how to install, configure, test and deploy.

Add a one-page map showing where the servers sit, what talks to what, which cron jobs run overnight and who to call when payments fail. Draw it by hand if that is quicker. Keep it current.

Record the odd things too. A manual export at month-end, an SSL certificate renewing in spring and a script that must run after each release all live in one person’s head. Get them out.

Use company-owned accounts with two named admins on every critical system. Turn on two-factor sign-in, keep recovery codes in a shared password vault and give each contractor a limited login that you can switch off the day they leave.

Require every change to pass through the repository as a pull request with a short description, a release note and a rollback step. The habit costs minutes. It saves the next handover from turning into another rescue. Nobody should hold the only copy.

Finish with a test. Ask someone who has never seen the app to deploy it from your notes alone, then fix every place where they get stuck and run the test again.