How to hand over a project so the next developer can pick it up

A project is not finished when it launches. It is finished when someone who has never seen it can run it, change it and fix it without calling the original team.

Most businesses discover this the hard way. The developer relocates, the agency closes or the relationship sours, and suddenly nobody can log in to the server, renew the domain or explain why the payments stopped. We have been called in to recover every item below for a client at some point. None of them is expensive to get right at the start.

1. Ownership: is it actually yours?

Check that each of these is registered to the company, using a company email address more than one person can access:

• The source code, in a repository (GitHub, GitLab or similar) owned by your organisation, with the developers added as members rather than owners.
• The domain name, at a registrar account in the company’s name.
• The hosting or cloud account, ideally paid with a company card.
• The Google Play and Apple developer accounts, if you have mobile apps. These are often opened under a developer’s personal name, and moving an app between accounts later is slow and sometimes impossible.
• Accounts with payment gateways, SMS providers and every other service the system depends on.

2. Access: can you get in without them?

• Every password and API key stored in a shared password manager the company controls, not in a chat thread or a developer’s notebook.
• Two-factor authentication tied to company devices or numbers, not to one person’s phone line. A lost SIM should not lock you out of your own servers.
• Former team members removed from every account on the day they leave, and a list showing who has access to what.

3. Documentation: can someone new understand it?

You do not need a manual. You need a few short documents that answer the questions a new developer asks in their first week:

• A readme that takes a developer from downloading the code to running it on their own machine in under an hour.
• A one-page overview of how the parts fit together: the app, the database, the background jobs and the outside services.
• How to deploy a change, step by step, and how to roll one back.
• Every setting and environment variable the system needs, and what each one does.
• The known problems: the slow report, the workaround in the payments code, the thing that breaks on the first of the month.

4. Infrastructure: could you rebuild it?

If your server disappeared tonight, how long would it take to stand the system up again? The answer should be hours, not weeks. That means the setup is described in scripts or configuration files kept with the code, not in one person’s memory of what they clicked two years ago.

5. Services and renewals: what will expire?

Keep a simple register of every outside service the system uses: what it does, what it costs, the currency it bills in, whose card pays and when it renews. Expired domains and lapsed SSL certificates are among the most common causes of sudden outages we see, and both are entirely avoidable.

6. Data: is it backed up, and has anyone restored it?

A backup that has never been restored is a hope, not a plan. Confirm where backups are stored, how often they run, how long they are kept and when someone last restored one to prove it works. Make sure at least one copy lives outside the main hosting account.

7. The walkthrough

Finally, a recorded session of about two hours in which the outgoing team walks the incoming team through the parts that are not obvious. Every codebase has them. Keep the recording with the documentation; it will be watched again.

The test that proves it worked

Ask a developer who has never seen the system to get it running using only the repository and the documents, without calling anyone. Wherever they get stuck is a gap in your handover. Fix it, and repeat until they do not get stuck.

Ask for it now

If your current vendor cannot give you this list today, ask for it now, while the relationship is still good. A vendor confident in their work will not mind. It is the standard we hold ourselves to: from day one, the code, credentials, documentation and accounts are in the client’s name, so they can take them anywhere.