Handover is a deliverable, not an event
Projects end with a launch and an invoice, and the question of what you actually own arrives months later when you need to change something. Agreeing the list at the start costs a paragraph; agreeing it at the end costs a negotiation.
1. The code, in your account
In a repository your organisation owns, with full history — not a zip file delivered at the end. History is what makes future changes safe, and it cannot be reconstructed.
2. Credentials on your accounts
Hosting, domains, databases, and third-party services registered to your company, with the agency granted access — not the reverse. Otherwise leaving is a migration, and it is precisely how an unowned integration is born.
If the agency’s email address owns the domain, you did not buy software. You rented it.
3. How to run it locally
Instructions another developer can follow to get it running, verified by someone who didn’t write them. This is the same bar as production readiness: someone who didn’t build it must be able to work on it.
4. How to deploy and roll back
The release process, written down, including how to undo a release. A team that cannot deploy cannot fix anything urgently regardless of who holds the code.
5. The decisions and their reasons
A short record of the significant architectural choices and why. Without it, every future team relitigates settled questions — and cannot tell when a rewrite argument is legitimate.
6–7. Known issues and what happens next
An honest list of shortcuts and known bugs, plus the support arrangement in writing: response times, rates, and who to contact. A supplier who won’t write down the first list is telling you something useful.