The handover package: what to demand when your developer moves on
Every client relationship ends eventually, and rarely on schedule. The developer goes on holiday, gets sick, takes another job, or the agency closes. The difference between an inconvenience and a hostage situation is a handover package. It costs the studio a day or two to assemble and is worth negotiating into the contract at the start, not at the goodbye meeting.
What should be in it
- Access, not passwords in a PDF. Repositories transferred to the client's own GitHub or GitLab organization, plus a shared password manager vault pointing at the server logins, hosting panel, domain registrar, payment dashboards, and email DNS. Passwords pasted into documents get forwarded and never rotated; a vault keeps them rotatable and revocable.
- An inventory of what runs where: app server, database, cron jobs, queues, object storage, and every third-party account (payments, transactional email, monitoring) with its purpose and who pays for it.
- Deployment steps that go all the way from "fresh machine" to "new version is live". If the answer to "how do we deploy" is one person's name, that answer has a shelf life.
- A runbook for the boring failures: how to restore a backup, where the logs live, how to restart the services, and who to email at the host when the host is the problem.
- The terms: what warranty support covers and until when, where the line between a bug and a new request sits, and who owns the code license.
Documentation that people actually read
Most handover docs die because they're written for an imaginary auditor instead of the next person at 2am. What survives is short, current, and pointed. A markdown file inside the repository beats a forty-page PDF sent by email, because it can't get lost separately from the code and it can be updated with the same pull requests that update the app. Prefer commands you can copy and paste over prose describing them; screenshots go stale within months, a working command doesn't.
One rule of thumb holds across projects: if a procedure is needed rarely, write it as numbered steps. If it's needed often, stop documenting it and turn it into a script instead.
The 30-day test
Before the contract ends, the client, or a neutral developer hired for a day if the team is small, should be able to:
- Log into every system in the inventory without asking anyone for a password.
- Deploy a trivial change, even something as small as editing a text string, and see it live.
- Restore yesterday's backup into a staging environment.
- Pause the old relationship for a week and notice no difference.
If any of these fail, the project isn't finished, whatever the final invoice says. The deploy check is the one that fails most often, and the backup restore is the one that quietly saves companies, because a backup that was never restored is a hope, not a backup.
Inheriting a project with no package
Plenty of first weeks on inherited code are archaeology instead of development, and clients often don't expect that. If you take over a product with no package: assume nothing about access, verify everything by logging in, rotate every credential the previous team ever saw, and find out where the backups go and whether a restore was ever tested. Budget a week or two for this detective work before promising feature dates. It is the cheapest way to buy back certainty about a system nobody currently understands.
The handover package is the client's property in the most literal sense. They paid for the code, the domains, and the infrastructure; the map of how it all fits together is part of what they bought. Ask for it in writing, early, while the relationship is still good.