Writing

What a handover should actually contain

9 June 2026/1 min read

Ask a web vendor for their handover documentation before you sign. Not because you will read it. Because the answer tells you what kind of shop you are hiring, faster than any portfolio.

Here is what should be in it.

Every credential, in your name. Domain registrar, DNS, hosting, CRM, email sending, analytics, phone. Not a shared login on their account. Yours, with your recovery email and your card where money changes hands.

Where the DNS actually lives. This one catches people constantly, because the registrar and the nameservers are frequently different companies. A client who does not know this will spend an afternoon editing records at the registrar that have no effect on anything, and conclude their site is haunted.

How to make the three changes they will actually want. Not a manual. Three specific procedures: change the phone number, add a service, update hours. With screenshots. Everything else can wait for a phone call.

What breaks and what it looks like. Certificates expire. Integrations detach. Say so, say what the symptom is, say who to call.

What is running on a schedule and where it sends. Every automation, its trigger, its destination. When somebody eventually gets an email they do not understand from a system nobody remembers configuring, this is the page that answers it.

A recording. Twenty minutes, screen captured, walking through the site and the admin. This is the single most valuable artifact and the one most often skipped. People do not read documentation, they scrub through video.

I write this at the end of every project and it takes a few hours. Clients rarely open it in the first year.

Then somebody leaves, or a card expires, or they hire somebody new, and it is the most valuable thing I gave them. The whole point of a handover is that it is useful on the worst day, and the worst day is not scheduled.