Skip Navigation
Let’s work
AI, Process 1 August 2026 1 min read

The handover, and why it is the last thing we do

A click-through guide to your own site, on the day it launches, shareable with whoever joins later.

The handover is the last thing we do on a project. It is also the first thing we design for — and those two facts are the whole point of this piece. If you decide on the last day how a client will run their own website, you have already built something they will need you for. Decide it on the first day and you build a different site.

What usually passes for a handover

Ask around and you will hear the same three versions.

  • The login email. A username, a password, and good luck. Everything the agency knew about the site stays with the agency.
  • The ninety-minute recording. Made once, on launch day, never watched to the end. By the time anyone needs the bit at 01:12:40, the interface has changed and the person in the call has left.
  • The PDF. Forty pages of screenshots, out of date the week after it is written, saved somewhere nobody can find.

None of these are handovers. They are receipts for one. The test is not whether something was sent — it is whether a person who joins your team in eighteen months can change the homepage without phoning us.

What actually changes hands

Six things, on every project. Not a premium tier, not a line item to be cut when the budget tightens.

  • Live team training, and a shareable, site-specific interactive guide. The walkthrough happens with your people, on your site, and it leaves something behind.
  • A curated stack with no abandoned plugins or hidden bloat. You should be able to name every extension on your site and say who maintains it.
  • The design system, documented in plain language. What the colours are for, what the spacing steps mean, which heading does which job.
  • Code structured for any capable developer — not a proprietary dependency that only works while we are in the room.
  • Every asset, credential and account in your ownership. Hosting, domain, analytics. We help configure them; we do not resell access to your own infrastructure.
  • Thirty days of post-launch support, with ongoing care available if you want it afterwards — and no penalty if you don’t.

Why it is a click-through guide, not a video

A recording answers questions in the order we thought of them. A guide answers them in the order you hit them.

Ours is built from the live walkthrough and then made navigable: your actual templates, your actual field names, the specific job you are trying to do. Somebody who needs to swap a case study opens the bit about case studies. They do not scrub through a video hoping to recognise a screen.

It is also shareable, which matters more than it sounds. The person trained on launch day is frequently not the person doing the job two years later. Marketing coordinators move on. Founders hand the website to someone else the moment they can. A handover that only exists in one person’s memory has a resignation letter attached to it.

The next-developer test

Here is the standard we hold ourselves to, and it has nothing to do with being nice. The next developer to open this site should be able to understand what they are looking at.

Not because we expect to be replaced, but because a build that only we can maintain is a build with a hostage in it. Clients feel that even when they cannot name it — it is the low-grade dread of not knowing whether you are allowed to leave. Removing it is worth more to a working relationship than any retainer clause.

It is also just a good engineering constraint. Code written so a stranger can read it tends to be code that is easier to change, and easier to change is the whole ballgame over a five-year life.

Designing for the handover changes the build

Three concrete examples of what that constraint actually does.

Editors never enter the layout layer. Content is edited through structured fields, so writing a paragraph cannot break a page. This is a decision made in the first week of the build, and it is the difference between a team that publishes confidently and a team that is frightened of their own website.

The stack stays small on purpose. Every plugin added is something someone has to keep patched after we have gone. Independent research on the WordPress ecosystem found that 46% of the vulnerabilities disclosed in 2025 had no fix available from the developer at the moment they became public — which tells you that “is it maintained, and by whom?” is not a paranoid question. Each extension on your site should be there because it earned its place.

The design system is written down in words, not just built in code. A colour named accent that is used for one specific job is a rule your team can follow. A hex code buried in a stylesheet is a thing your next designer will guess at and get wrong.

The thirty days after

Launch is when a site meets its real users, and real users find things. So the month after launch is included: bugs fixed, small content edits covered, questions answered while your team is still building the habit.

When the thirty days close, ongoing care is available — and it is genuinely optional. If a client never needs us again, the handover worked.

Questions to ask whoever built your last site

If you already have a website and you are not sure where you stand, these five will tell you quickly.

  • Whose name is on the hosting account, the domain and the analytics property?
  • Can you list every plugin on the site, and say who maintains each one?
  • If your main contact left tomorrow, what would a new starter read?
  • Can a member of your team change a page without being able to break the layout?
  • What would it take to move to another studio — and has anyone ever told you the answer?

An awkward silence on any of them is the finding.

FAQs

Can our team edit the site after launch?
Yes. Every handover includes live training and a site-specific interactive guide, and editors can change content without entering the layout layer.

Do we own the hosting and accounts?
Yes. Hosting, domain, analytics and credentials sit in your name. We help configure them, but do not create dependency by reselling access.

What if we want to move to another studio later?
You take everything with you, because it was already yours. The code is structured for any capable developer, and the documentation goes with the site rather than staying with us.

Does the guide stay accurate as the site changes?
It is tied to your templates and field names, so it holds for the structure it documents. Where a build changes substantially, the guide is updated alongside it rather than left to drift.

Next steps

Pixelgbra Pixelgbra Studio
Next in the journal