How to hand over a site your AI agent built

A developer builds a bakery's website with his AI agent over two weekends. The site is a folder of pages and images, the project lives in a code repository on his own account, and it's published on his hosting account. The bakery loves it. Six months later the owner writes: "My nephew is going to look after the website now. Can you send it to him?"

Send what, exactly? It's a question every one-person AI agency meets sooner or later. With a site your agent built, "the website" is several things in several places, and the client only knows about the one they can see.

To hand over a site your AI agent built, give the client four things: the built site as files, the source project the agent worked from, the accounts the site runs on in the client's name, and a one-page note saying what's where. Before any of it, check one named version, remove anything private, and write down which version you handed over.

What does "the website" mean when an agent built it?

Name the parts before you move them:

Part	What it is	Why the client needs it
The built site	The pages, styles and images that go live	So they can publish it anywhere, even without the tools you used
The source project	The files the site is built from, plus the agent's project instructions	So the next person, or the next agent, can change it properly
The accounts	Domain, hosting, repository, forms, analytics	So nothing depends on your login
The notes	One page on what's where and how to change it	So the nephew doesn't have to guess

Most handover trouble comes from handing over the first row and forgetting the other three.

What should you check before handing over?

Hand over a site you've checked, not whatever happens to be in the folder.

Pick one version and name it. "Bakery site, version 7, 19 June." Check that version on a computer and on a real phone with a website QA checklist: words against the brief, every link and form, images, the basics of accessibility. Then hand over that version and nothing newer.

Take out anything private. Agent projects collect things over time. Before you package anything, look for:

• keys and passwords, including any in settings files;
• the agent's notes, if they mention other clients, your prices or your own accounts;
• test pages, old drafts and unused images;
• anything with a licence the client doesn't have, such as a font or photo licensed to you.

Keep the project instructions, cleaned. The file where you told the agent how this site is built (the style, the structure, the rules) saves whoever comes next a lot of guessing. Keep it, minus anything personal to your agency.

Decide who approves the release. Your agent can package and even publish the files. It shouldn't be the one deciding which version reaches the client. Approving what your agent sends before it goes out keeps that decision with you.

How do you package the files?

Make two bundles and one note:

1. The built site as a ZIP. The folder of files that goes live, zipped. This is the version anyone can put on almost any host. Cloudflare's documentation for Pages, for example, says its Direct Upload option accepts a ZIP file or a folder dragged into the dashboard. It also warns that a project created this way can't be switched to automatic deployments from a code repository later, so the client should choose how they'll publish before they upload.
2. The source project. Either a ZIP of the whole project or, better, the code repository itself (more on moving that below). Include a short "how to rebuild" section: what to install, which command builds the site, where the output goes.
3. The handover note. One page, covered further down.

Name the files with the client, the version and the date. "bakery-site-v7-2026-06-19.zip" will still make sense in two years.

How do you move the code and the hosting to the client?

The cleanest handover is the one where the client owns the accounts from the start, and you only have to leave. If they don't, move them now.

The repository. On GitHub, you can transfer a repository to the client's own account from the repository settings. GitHub's documentation says the new owner receives an email to accept, and the invitation expires if they don't accept within a day, so tell them it's coming. After the transfer, the original owner is added as a collaborator, and links to the old location redirect to the new one. Remove yourself once they've confirmed they can get in.

The hosting. Either transfer the project to the client's hosting account, or create a fresh project in their account and publish the ZIP there. Then point the domain at the new location and check the live site again.

The domain, email and listings. These should already be in the client's name. If they aren't, the website handover checklist goes through what the client should own after a website handover, account by account.

Forms and small services. Contact forms, booking widgets and analytics often sit in separate accounts. List each one, and either transfer it or set the client up with their own.

What should the handover notes say?

One or two pages the client can keep, written for the nephew rather than for you:

• What's where. Hosting, domain, repository, forms, analytics: the service, the account it's in, who can log in.
• Which version this is. Version number and date, and what changed since the last one they approved.
• How to change the words. If the site has an editor, how to use it. If you built a client editable website, point to the parts they can safely change and the parts they shouldn't touch.
• Where the words came from. If you wrote the small business homepage content from the owner's answers, say where those answers are kept, so the next person can update them.
• How to rebuild and publish. The same short steps as in the source project.
• What you'll still do, if anything. Whether a care plan continues, or this is a clean break, and how to reach you.

What happens after the handover?

Agree in writing when your responsibility ends. "From 1 July, changes to the site are yours or your nephew's. I'm happy to quote for anything you'd like me to do." Keep your own copy of the handed-over version and the note, in case questions come later.

Then ask the client to check they can log in to everything on the list, while you're still around to help.

A short handover email ties it together. Send it once everything has moved, and keep it:

1. The two ZIP files, or links to them, with the version number and date.
2. The handover note.
3. A list of every account that has moved, and the date it moved.
4. Anything that still needs the client to act, such as accepting the repository transfer.
5. The date your responsibility ends, and how to reach you after it.

If the client stays on a care plan with you, the handover is simpler but still worth doing. The client then owns the accounts and has a copy of their site, and you look after it by invitation. That's a better footing for both of you than a site that only exists in your accounts.

Where Volant fits

Volant is built for building, reviewing and delivering client websites. Volant has version history for every website, so you can compare versions and go back to any earlier one. You choose which one goes live, and you can download the version you chose as a ZIP to hand over. Whatever you use, hand over one checked version, with the accounts in the client's name and a note the next person can follow.