Tutorials
How to Hand Off an AI-Built Website to a Client — Without Becoming Their Helpdesk
Handing off an AI-built (vibe-coded) website means converting a pile of custom code into something a non-technical client can run: a frozen, verified structure; a CMS layer for safe self-editing; scoped permissions; one recorded training session; and support boundaries in writing. Skip the CMS layer and every typo becomes your email; skip the boundaries and every idea becomes free work; skip the training recording and you'll give the same tour eleven times. This is the complete playbook — five steps, a training agenda, a handoff email template, care-plan pricing that actually gets accepted, and the mistakes that create helpdesk agencies.
Key takeaways
- The build is ~10% of a client website's life; handoff quality decides the other 90% — and whether the project stays profitable after invoice one.
- A vibe-coded site without an editing layer is structurally un-handoffable: beautiful, fast, and completely opaque to its owner.
- The five-step process: freeze & verify the structure → install the CMS layer on the client's hosting → configure editable vs. locked → train once, record it → put support boundaries in writing.
- Clients need to edit text, images, sections, and read their form submissions. They do not need — and should not have — layout systems, code, or hosting access.
- Drafts + version history are non-negotiable: the client's willingness to click "edit" comes entirely from knowing nothing can permanently break.
- The handoff email is a document of record: credentials, training video, what's included, what's billable, and the care-plan offer — one message, referenced forever.
Step 1 — Freeze and verify the structure
Before anything is handed over, the site must be finished in structure, not just in looks — because after handoff, structural changes become change requests, not vibes. Run the final pass as a checklist, not a stroll: every page reviewed on real mobile and desktop widths; every form submitted and its email received; 404 page, favicon, meta titles/descriptions set; legal pages present and current; performance sanity-checked; the safety guardrails list ticked (secrets in env config, forms validated server-side, HTTPS forced). If you built with Claude Code, this is the last cheap moment for structural prompts — the full build walkthrough covers that phase.
Two under-rated moves in this step. Name things for humans: the labels a client will meet in the editor should read "Opening hours" and "Team", not section-cta-3 and div-wrapper-2 — five minutes now, dozens of confused emails saved. Write the one-page site map: pages, their purpose, what's dynamic — it becomes page one of the handoff document and your own memory in eighteen months.
Step 2 — Install the CMS layer on the client's hosting
This is the step separating a handoff from an abandonment. Two decisions live here.
Whose hosting? The client's — their asset, their invoice, their contract, their independence. Sites on your hosting make you an involuntary provider, create awkward dependencies if your business changes, and muddy GDPR responsibility. You keep an admin login for support; ownership sits where it belongs. (Bonus for German clients: their existing Strato/IONOS/all-inkl plan is almost certainly a standard PHP account — which is all you need.)
Which layer? The requirements list, tool-agnostic: runs on the hosting the client already pays for; preserves your generated code untouched; edits happen as drafts; version history exists; forms and media are handled; and ideally the client edits on the page, not in a disconnected form. With VibeMS this whole step is deliberately boring: upload one file via FTP, open it in the browser, and the installer wraps the exact site you built — structure untouched, PageSpeed untouched — with the editor, drafts, versions, media library, form inbox, backups, and one-click updates. A single-site license is a $29 one-time line item you pass through on the invoice. Whatever you choose, verify after install that the live site is byte-for-byte the site you shipped.
Step 3 — Configure what the client can (and can't) touch
Good handoffs are permission design. Walk every page and decide per element:
Editable: headlines, body copy, images, opening hours, prices, team members, testimonials, blog/news posts — everything the client will realistically want to change, which is 95% content. Locked: layout and spacing, brand elements, navigation structure (usually), legal texts if you carry liability for them, anything whose breakage would be a design incident. The target state: a client who can do everything they'll want and nothing they'd regret at 11 p.m.
Create the login now — their email, their password flow, never a shared account of yours. And decide the AI question explicitly: if the deal includes future AI drafting (the client's marketing person wants Claude to draft blog posts via MCP), configure that as a separate token, scoped to drafts only, documented in the handoff email. Default for everyone else: off.
Step 4 — Train once. Record it.
One session, 30–45 minutes, on their real site — demos don't build confidence, their own headline changing does. The agenda that works, in order:
| Min | Segment | The point |
|---|---|---|
| 0–5 | Log in, tour the dashboard | "This is your site's home." |
| 5–15 | Click a text → edit → see the draft badge → publish | The core loop, done by their hands |
| 15–20 | Swap an image via the media library | Second-most-common task |
| 20–25 | Add a section, hide a section | Power without layout danger |
| 25–30 | Find the form submissions | "Your inquiries live here, not in a plugin" |
| 30–35 | Restore a previous version | The confidence moment — show it, don't just mention it |
| 35–45 | Their questions, on their content | Surface the real use cases |
Do the version-restore demonstration early enough that it lands: "Nothing you do here is permanent — watch." That single moment converts anxious owners into active editors.
Record the session (screen + voice) and send the video with the credentials email. That recording answers 80% of future "quick question" emails before they're written, onboards the client's next employee for free, and documents that training was delivered.
Step 5 — Put the support boundary in writing
The handoff email is the contract's friendly epilogue. It states, in plain language: what they now do themselves (content edits), what's included if something is broken (defects fixed free for X months), what is billable new work (new pages, features, design changes — at your rate or via care plan), and how to reach you (channel + response time). Then — here, once, while the relationship is warm — the care-plan offer.
Template (adapt freely):
Subject: Your website — access, training video & how support works
>
Hi [Name],
>
your website is live and officially yours. Here's everything in one place:
>
Access: [URL]/admin — username: [email]. Set your password via the link in the separate email. Training video: [Link] — the 35-minute walkthrough we recorded together. Everything we covered, rewatchable anytime. What you edit yourself: all texts, images, sections, opening hours, and your form inquiries (Dashboard → Submissions). Every change is a draft first — nothing goes live until you hit Publish, and every version can be restored. Included until [date]: if anything is genuinely broken, we fix it free. Just reply to this email. New work: additional pages, new features, or design changes are quoted separately at €[rate]/h — or covered by the Care Plan below. Care Plan (optional, €[X]/month): we keep an eye on hosting, backups & updates, include [Y] content changes/month done for you, and give you priority response. Reply "Care Plan" and it starts on the 1st.
>
It was a pleasure building this. Enjoy owning it. [You]
Pricing the care plan (so it actually sells)
Anchor it to their time, not your tasks. Market-typical for content sites: €49–79/month "Essential" (monitoring, backups verified, updates, 30 min content changes) · €99–149 "Comfort" (Essential + 1–2 h changes, small SEO upkeep, priority) · project-rate "On demand" for the rest. Present exactly one recommended tier in the email. Conversion truth: care plans sell at handoff or never — the moment of maximum goodwill and maximum "I don't want to think about this" is now. A 30–40% take rate on content-site clients is normal and turns one-off builds into recurring revenue without becoming a hosting company.
The handoff checklist (print this)
| ✔ | Item |
|---|---|
| ☐ | Final QA: all pages, breakpoints, forms tested; legal pages; meta data; favicon; 404 |
| ☐ | Human-readable names for pages & sections; one-page site map written |
| ☐ | CMS layer installed on client's hosting; site verified untouched; PageSpeed re-checked |
| ☐ | Editable vs. locked configured; client login on their email |
| ☐ | AI/MCP access: off, or separate draft-only token, documented |
| ☐ | Backups + version history verified with one real restore test |
| ☐ | 30–45 min training on the live site, recorded |
| ☐ | Handoff email sent: access, video, boundaries, care-plan offer |
| ☐ | Invoice: build + license pass-through + handoff/training as line items |
| ☐ | Calendar note: check-in at 30 days ("everything running? need the care plan after all?") |
The five handoff mistakes that create helpdesk agencies
1. No editing layer — "just email me changes" is a subscription to unpaid work. 2. Client on your hosting by default — you've founded a hosting company with one angry customer segment. 3. Training without recording — you'll perform the same 40 minutes for every new employee they hire. 4. Boundaries stated verbally — verbal boundaries don't exist; the email does. 5. Full access "to be flexible" — the client who can edit the navigation will, at some point, edit the navigation. Permission design isn't distrust; it's the kindness of making mistakes impossible.
What changes for your business
Designers who systematize this report the same arc: support email drops toward zero, clients stop fearing their own website and start using it, care plans add a recurring floor under revenue, and the conversation shifts from "can you change this text" (unbillable interruption) to "can you build us a landing page for the spring campaign" (billable work). The handoff isn't the end of the project. It's the beginning of the profitable part of the relationship.
FAQ
How do clients edit a website built with AI tools like Claude Code?
Through a CMS layer installed over the generated code. Systems like VibeMS run on the client's standard PHP hosting and add on-page visual editing with drafts and version history — the client clicks the actual text on the actual page, changes it, and publishes, with no code and no AI skills involved.
Should the website run on my hosting or the client's?
The client's. It keeps ownership, invoices, GDPR responsibility, and continuity where they belong, and prevents you becoming an involuntary hosting provider. You keep an admin login for support; the asset is theirs.
What should a website handover include?
A QA'd site; an editing system with the client's own login and scoped permissions; verified backups and version history; one recorded training session; and a handoff email documenting access, the training video, support boundaries, and any care-plan offer.
How long should client CMS training take?
30–45 minutes on their live site covers everything a content editor needs: the edit-draft-publish loop, images, sections, form submissions, and — crucially — a version restore demonstration. Record it; the video handles repetition forever.
Can the client break the site while editing?
Not in a draft-first system: every change stays a draft until deliberately published, version history rolls anything back, and structural elements are locked. The worst realistic outcome is an unpublished odd draft — which is the design goal.
What should I charge for a website care plan?
Content-site market range: €49–79/month for monitoring + backups + minor changes, €99–149 with monthly content work and priority response. Offer one recommended tier in the handoff email — that moment converts at 30–40%; cold upsells later rarely do.
What if the client wants AI to write their content later?
Configure it deliberately: a separate MCP token scoped to draft-only access lets Claude or Codex draft posts and page copy, while publishing stays with a human. Document the token in the handoff email so everyone knows the AI's exact limits.
Do I need a formal handover document?
The handoff email is the document if it contains access, the training video, included support, billable definitions, and the care-plan terms. For larger clients, attach the one-page site map and a permissions summary — still one page, still findable in a search.
How do I hand off a website built with Lovable, Bolt, or v0?
Those platforms output framework apps tied to cloud deployment, so "client edits on their own PHP hosting" doesn't map cleanly. For content sites, the smoother path is generating portable code with Claude Code or Codex and adding a CMS layer — the workflow this guide assumes.
When should I not hand off self-editing?
When the client explicitly wants full-service (some do — that's a care plan, priced accordingly), or when the site is a regulated context where every published word needs review. Then configure the CMS so the client drafts and you publish — same tooling, inverted roles.