What a proper project handover actually contains
You should be able to hand any project to another developer and have them deploy it without a phone call. Most handovers fail that test.
Why this matters more than it sounds
The risk in hiring an external developer is not that the work is bad. It is that six months later you need a change, the person who built it is unavailable, and nobody else can safely touch it. That risk is priced into every quote you receive, whether or not anyone says so.
A handover that genuinely works removes that risk, and it is worth insisting on before the final invoice rather than after.
Everything needed to run it locally
- The repository, with full history — not a zip of the final state.
- A documented way to start it: exact commands, in order, that work from a clean checkout.
- An example environment file listing every variable, with safe placeholder values.
- A database schema plus seed or anonymised sample data.
- The versions that are actually required — language, database, extensions.
The test is simple and should be performed, not assumed: a developer who has never seen the project follows the document on a clean machine and gets it running. If that has not been tried, the document is a guess.
Everything needed to deploy it
How does code get to production? Which branch? Is there a build step? What has to be run after deploying — migrations, cache clears, queue restarts? How do you roll back?
Rollback is the one most often missing and the one you need under the most pressure. It should be written down as a sequence of commands, not described in principle.
Everything needed to fix it at 2am
- Where the logs are, for the application, the web server and the database.
- What is scheduled — every cron job, what it does, what breaks if it stops.
- Which third-party services it depends on and where those accounts live.
- Where backups are, how often they run, and evidence a restore has been tested.
- Which alerts exist and who receives them.
A backup nobody has restored is a hypothesis, not a backup. The handover should record the date of the last successful test restore.
Ownership, which is the part people forget
Accounts registered in the developer's name are a genuine business risk. The domain, the TLS certificates, the hosting, the DNS, the payment gateway, the error tracking, the third-party API keys — all of it should be in accounts the client owns, with the developer added as a user who can be removed.
This is far easier to arrange at the start than to unpick at the end, and unpicking it later is a common source of genuinely nasty disputes.
A short version you can send to a developer
Ask for: repository with history, a runbook that has been tested from clean, an environment variable reference, deploy and rollback steps, a list of cron jobs and external dependencies, backup location with a tested restore, and confirmation that every account is in your name.
Any competent developer will already have most of it. The ones who object to producing it are telling you something useful.
Common questions
When should handover be agreed?
At the start, in writing, as part of the scope. Handover negotiated at the end tends to be thin because the budget is spent and attention has moved on.
Is documentation enough on its own?
No. Documentation that has never been followed from a clean machine is usually wrong in small ways that cost hours. The verification is the deliverable, not the document.
What if the project uses a lot of third-party services?
Then the account inventory matters more, not less. List every service, what it does, which account owns it and what happens if it is switched off.
Need this done properly?
Describe the problem in plain language and I’ll tell you what it actually needs — including if that is less work than you expected.