There is a version of software delivery where the last day is a demo, a zip file and a thank you. Six months later the client cannot deploy a change, cannot find where anything is hosted, and cannot get an answer from whoever built it.
They own an asset they cannot operate. That is not a delivery.
What actually has to change hands
Access first, and in the client’s own name. Domain registrar, DNS, hosting, repository, error tracking, analytics, the mail service, the payment gateway. Accounts created by the agency and owned by the agency are the single most common thing that traps a business with an agency it wants to leave.
We create these in the client’s name from the start where we can, and transfer the rest at the end. It occasionally costs us a bit of convenience during the build. It has never once cost us a client.
Then the things that are not accounts: how to deploy, how to roll back, what runs on a schedule and what breaks if it stops, where backups are and — the part everyone skips — evidence that a restore has been tried.
Write it for the person who arrives later
Documentation written for the current team is a list of reminders. Documentation written for a stranger is a set of instructions, and the difference shows up in the first sentence.
The useful form is short and specific: what this system does, what it depends on, what happens on a normal day, what to do on a bad one. Not a tour of the code — the code is there and it changes. The things that are hard to reconstruct are the decisions and the operational facts.
Then be reachable, and say for how long
A handover with no support period is theoretical. Somebody will find something in the first month, and the honest arrangement is to say plainly what is covered, for how long, and what happens after.
The measure we hold ourselves to is simple: can a competent developer who has never met us take the project on without calling us? If the answer is no, we have not finished — we have made ourselves necessary, which is a different thing and a worse one.