A website handover checklist: accounts, domain, forms and the note
A handover is finished when the client can run the site without phoning you: they know who owns the domain, where enquiries arrive, how to make a small change and what to do if something breaks. This checklist walks through those decisions in order, with the parts Anticode covers and the parts you write or set up yourself.
Decide the ownership model first
Most handover trouble starts months earlier, when nobody decided whose account the site lives in. Make that choice at kickoff and write it into the proposal. With Anticode there are three workable models, and each changes the checklist below.
| Model | How it works | Suits |
|---|---|---|
| You keep hosting it | The project stays in your Team or Agency workspace; the client gets a seat as a member, or sends edits to you | Clients on a care plan who rarely edit themselves |
| It lives in the client's workspace | The client holds the Team subscription and invites you while you build; at handover you leave or drop to member | Clients who want full control and a direct billing relationship |
| The client takes the code | You export a single HTML file or a Next.js project, or push the Next.js app to their GitHub repository | Clients with their own developer or hosting |
A workspace belongs to the subscriber: projects, sites, domains and form data sit under it, and people work in it as owner, admin or member. If the client should own everything outright, the second model is cleanest, because nothing has to move at the end.
The checklist
- Domain registration. The domain should be registered in the client's name, at a registrar account they control, with renewal on their card. If you bought it for them, move it now, not when it's about to lapse.
- Domain connection. Confirm the custom domain is verified (Anticode uses a CNAME or TXT record) and the certificate has been issued. Write down which DNS records point at the site so the client's next IT person doesn't delete them.
- Form notifications. Submissions are saved in the dashboard and can be emailed to the account owner. If the site stays in your account, those emails come to you, so plan the client's own route.
- Connectors. Connectors are set per account, and each enabled one receives submissions from every site in that account or workspace, labelled with the site's name. In the client's own workspace, connect their Slack, sheet or CRM directly. If the site stays in yours, don't add the client's Slack, or it gets every client's enquiries; send a webhook to an automation that filters by site instead. Credentials are sealed and write-only, so the client enters their own.
- Two-factor sign-in. A site that collects data can't be published until the account owner and the person publishing have two-factor sign-in on. Check the client's people have it, and that their recovery codes are stored somewhere other than one phone.
- Access. Add the client's people to the workspace with the right role, or remove your own access if it's their workspace. Remove anyone from your side who no longer needs it.
- Code, if promised. If the contract includes code, export it now and hand over the file or the repository, together with the brief that produced it.
- A known-good version. Note the version number of the site as handed over. Version history keeps the most recent saves (up to a number set by the plan) to preview and restore, so the client has a recent point to return to.
- The handover note. One page, written by you. The next section covers what goes in it.
What to put in the handover note
Anticode doesn't produce this document, yet it answers the questions the client will have in six months when you're busy. Keep it short enough to be read.
- Where the site lives, who owns the account, and which plan it's on (link to the pricing page rather than quoting amounts that will change).
- The domain: registrar, renewal date, and the DNS records that must stay.
- Where enquiries go: email address, channel or sheet, and who answers them.
- How to make the three edits they'll actually make: change opening hours or prices, swap a photo, update a CMS entry such as a menu or team member.
- How to undo a mistake: open history, preview an earlier version, restore it, publish.
- What isn't included: anything in the scope you agreed to leave out, and what support you offer after handover.
Mistakes that cost the most
The expensive ones are quiet. A domain in a freelancer's personal account that lapses years later. Enquiries still emailing a designer who left. A Google Sheet connector feeding a spreadsheet the client can't open. Each submission goes to a connector once, without retries, so a broken connector loses its copy; the dashboard keeps the full record, but only if someone looks there.
Test the forms last, from a phone: send one enquiry, confirm it arrives where the client expects, then ask the client to send one too.
How you know the handover worked
The client has made one real edit on their own, received one real enquiry in their own inbox or channel, and can tell you who renews the domain. You can sign out of their workspace without anything breaking.
Limits to plan around
- No move between accounts. Anticode has no button that transfers a project from your account to a separate client account, which is why the ownership model has to be decided at the start.
- Exports leave the platform behind. An HTML or Next.js export runs without Anticode, so the dashboard, connectors and version history don't come with it. The Next.js project has its own server routes for contact, bookings and newsletter, set up by whoever hosts it.
- No client-only role. Clients in a workspace are members like anyone else, and members can publish.
Questions people ask
Should the client own the domain?
Yes. Register it in their name at a registrar account they control. You can still connect it to the site; owning the registration is what protects them if you part ways.
Can I give a client access without giving them the whole account?
In a Team or Agency workspace you can invite them as a member. Members can build, edit and publish, but can't delete projects or take sites down.
What if the client wants to host the site somewhere else?
Export it as a self-contained HTML file or a Next.js project, or push the Next.js app to a GitHub repository they own. Read about the Next.js export first, so they know what their developer takes on.