How to hand off a website to a client

Most website projects do not go wrong during the build. They go wrong in the two weeks after it — when nobody can remember who owns the domain, the client cannot log in to change a phone number, and you are answering questions for free eight months later.

A handoff is not an email with a password in it. It is a deliberate transfer of ownership, access, and knowledge. Here is how to run one properly.

Decide the ownership model before you build

This is the single decision that determines how painful the handoff will be, and it needs to be made at proposal time — not at delivery. There are three workable models.

1. The client owns everything

The client holds the domain registrar account, the hosting account, and the code. You are given access to build, and you give it back when you are done. This is the cleanest model and the easiest to walk away from. It is also the one clients trust most, because nothing about it is hostage.

2. You host it as a service

You keep the hosting under your account and bill monthly. This is legitimate and can be good recurring revenue — but only if the client knows that is the arrangement and can leave. If your care plan is really just leverage over their domain, you have built a hostage situation, and it will end badly and publicly.

3. Hybrid — client owns the domain, you host the site

In practice this is the best default. The domain is the one asset a business genuinely cannot afford to lose, so it should always be in their name, on their credit card. Hosting is a service you can provide and they can move.

What actually has to transfer

People remember the website and forget everything attached to it. Work through the full list:

• Domain registrar account, plus the auth/EPP code if it is moving registrars
• DNS records — export the full zone, not just the A record; email routing lives here too
• Hosting account and deploy access
• The source code, in a repository the client controls
• Design source files, and the license terms for every font, stock photo, and icon set
• Third-party accounts: analytics, forms, booking, payments, chat widgets
• Any API keys the site depends on, rotated so your personal keys are not left in production
• Email — if you touched MX records, confirm mail still flows after the switch

The font and stock licensing item catches people constantly. A license bought under your account often does not transfer to the client. Either buy it in their name or tell them plainly what they need to purchase.

Write the handoff document

One page. Plain language. Written for a person who does not know what DNS is. It should cover:

1. Where the site lives and how to log in
2. How to make the three edits they will actually want — text, images, and hours or contact details
3. Who to contact when something breaks, and what is covered
4. What you are explicitly not responsible for after the handoff date
5. Where the code and design files are

Record a five-minute screen capture walking through the common edits. It takes less time than the support emails it prevents, and clients consistently rate it as the most useful thing they received.

Set the support boundary out loud

Unpaid indefinite support is the default outcome of saying nothing. Name the boundary at handoff, in writing: a defined window of included support (30 days is common), then either a care plan or hourly work at a stated rate.

Clients almost never object to this. What they object to is discovering the boundary only when they hit it.

The part people skip: make sure they can actually leave

A handoff is only real if the client could move to another developer next month without your cooperation. That means the code has to be something a competent developer can pick up — not an export that only opens in one tool, and not a proprietary format that has to be rebuilt from scratch.

It is worth testing this before you promise it. Export the project, open it somewhere unrelated to the tool that produced it, and see whether it runs. If it does not, your client is locked in whether or not you intended that.