A clean website handoff means the client owns every account the site depends on (the domain registrar, DNS, hosting, the code repository and any third-party tools) and you have collaborator access, not the other way around. Then you give them a short document that says where everything lives, what it costs, when it renews and how changes get made. Set this up before launch, not after the final invoice.
The rule: the client owns the accounts, you get access
Freelancers and agencies often register the domain and open the hosting account themselves because it is faster. It is also how clients end up locked out of their own business: the freelancer moves on, the employee who held the login leaves, or a payment dispute freezes everything. Holding a client's accounts also makes you responsible for them, including the renewal you forget.
The fix is simple. The client creates each account with a company email address they control (a shared address like web@ is better than one person's inbox), pays with their own card, and invites you as a member or collaborator. You never need their password, and they can remove you in a minute when the work ends.
A portable site makes this much easier. A site exported as plain code, like the Next.js or HTML projects from FNJ's AI website builder for agencies, moves between accounts with no platform attached to it.
Who should own what
| Asset | Owner | Your access | Watch out for |
|---|---|---|---|
| Domain name | Client, in a registrar account in their name | None, or delegated access | Auto-renew on, client's card, client's business as registrant |
| DNS | Client (at the registrar or a DNS provider) | Member or delegated access | Email records (MX, SPF, DKIM) live here too |
| Hosting | Client's account or team | Team member | Plan terms on commercial use |
| Code repository | Client's GitHub account or organization | Collaborator | Protect the default branch |
| Analytics and Search Console | Client | Added user | Verify the domain on the client's account |
| Forms, booking, newsletter tools | Client | Added user where possible | Notifications going to a monitored inbox |
| Design source files | Usually you, unless the contract says otherwise | Full, as the owner | The client must still get the code |
The last row is worth agreeing in writing. Whatever happens to your working files, the client must always walk away with the code that runs the site and control of everything that serves it.
The domain: where most handoffs go wrong
The domain is the one asset you cannot rebuild. Lose it and you lose the site's address, its search history and often its email.
- If the client hasn't bought it yet, have them register it themselves while you share a screen. Ten minutes now saves a transfer later.
- If you already registered it, move it. Many registrars let you move a domain to another customer's account at the same registrar without a full transfer. To move it to a different registrar, turn off the transfer lock, request the authorization code (often called the EPP code), and have the client start the transfer at their registrar. Registrars often block transfers for a period after a domain is registered or transferred, commonly 60 days, so don't leave this until launch week.
- Check the registrant details. The legal owner listed should be the client's business, with the client's contact email.
- Turn on auto-renew with the client's card. An expired domain takes the website and the email down together.
Avoid changing nameservers on launch day. Move DNS a few days early, confirm email still arrives, then point the site at the new host.
Hosting in the client's name
FNJ's static HTML export can run on Cloudflare Pages, Netlify or any static host, and its Next.js project on a host that builds Next.js, such as Vercel or Netlify. Have the client open the account and invite you to their team, then:
- Connect the client's repository, or upload the built site for a drag-and-drop deploy.
- Add the custom domain in the host's dashboard. On Cloudflare Pages, that is the project's Custom domains tab; Cloudflare's custom domains guide covers apex domains and subdomains.
- Wait for the HTTPS certificate, then test both the bare domain and the www version and make sure one redirects to the other.
- Confirm that billing and outage emails go to the client, not to you.
Choose the plan with the client's use in mind. Vercel's free Hobby plan is for personal, non-commercial use, so a business site needs Pro ($20 per seat). Cloudflare Pages' free plan has no published bandwidth cap for static assets, allows 500 deploys a month and includes custom domains. Netlify's free tier is credit-based, with roughly 15 GB of bandwidth a month. For the deploy steps on each host, see how to deploy a website you built with AI.
The code: work in their repository, or transfer yours
There are two clean ways to give a client the code.
Work in their repository from day one. The client creates a GitHub organization (or uses their own account), creates an empty repository and adds you as a collaborator. Everything you build lands there, and when the contract ends they remove you.
Transfer a repository you created. GitHub can transfer a repository to another account or organization. Issues and pull requests move with it, and links to the old location redirect to the new one. The steps are in GitHub's guide to transferring a repository.
If you built the site with FNJ, it can push the code to a branch of a GitHub repository you own, which you can then transfer as above. The default branch stays untouched until someone merges, so the client can look at a preview of that branch on a Git-connected host before anything goes live. Also download a copy of the export, the Next.js project or the static HTML, and keep it with the handoff files. If the client's team has never used a repository, why your website should live in a GitHub repository explains version history and rollbacks in plain terms.
Before you hand over the repository, add a short README that answers four questions:
- How do you run and build the site? For a Next.js project, list the scripts in
package.json. For static HTML, there is no build step; any simple local web server previews it. - Where does each page live? A Next.js export from FNJ has one route per page; an HTML export has one HTML file per page and one stylesheet.
- How does a change reach the live site? Usually: merge into the default branch and the host deploys it.
- Who should they contact, and for what?
The handoff document
Code and accounts are not enough. The client needs a map. Keep it to one or two pages:
- Accounts. Registrar, DNS, hosting, repository, analytics, Search Console, form and booking tools. For each, the login email (never the password), who pays and the renewal date.
- Recurring costs. Every charge and when it bills.
- Common changes. Updating opening hours, replacing a photo, adding a team member, and who does each: the client, you under a care plan, or any developer.
- Where messages go. Form submissions, booking notifications, the public contact address.
- Support terms. What is included and what costs extra.
- Emergency contact. Who to call when the site is down.
Store it somewhere the client controls, such as their shared drive, with a copy in the repository.
A website handoff checklist
Before launch:
- Domain registered to the client, auto-renew on, client's card on file
- DNS moved early and email tested
- Hosting account owned by the client, on a plan that allows commercial use
- Repository in the client's account or organization, with you as a collaborator
- Custom domain connected, HTTPS working, bare and www addresses resolving to one version
- Search Console and analytics verified on the client's accounts
- Form, booking and newsletter tools sending to the client's inbox
At handoff:
- README and handoff document delivered
- A downloaded copy of the code delivered
- A walkthrough call, recorded if the client agrees
- Support terms confirmed in writing
After the contract ends:
- Your access removed from every account, or kept under a written care plan
- Any login details that were shared outside the invite system changed
A note on contracts
Who owns the code, the design files and the content is normally set by your contract, and the default rules differ from country to country. Many agencies state that ownership of the deliverables passes to the client on final payment, with exceptions for third-party licenses such as fonts, photos and software tools. This is general information, not legal advice. Have a lawyer in your country review your contract template.
Handing off an FNJ-built site
Sites built with FNJ are simple to hand over because there is nothing to untangle. The export is a Next.js App Router project or static HTML with no FNJ runtime, script or badge, FNJ does not host it, and it keeps working on the client's hosting if nobody opens FNJ again. See how FNJ's AI website builder fits agency client work and what is inside the exported code.
Frequently asked questions
Who should own a client's domain name?
The client. The domain should sit in a registrar account the business controls, with the business listed as registrant and the client's card set to auto-renew. An agency can have delegated access but should not be the owner.
Should the client pay for hosting directly?
In most cases, yes. When the hosting account and its billing are in the client's name, the site keeps running even if you stop working together, and the client receives billing and outage notices directly.
How do I transfer a GitHub repository to a client?
Use GitHub's repository transfer to move it to the client's account or organization; issues and pull requests move with it and old links redirect. Simpler still, create the repository in the client's organization at the start and work in it as a collaborator.
What should a website handoff document include?
Every account the site uses with its login email and renewal date, all recurring costs, how common changes are made and by whom, where form and booking messages go, what support covers, and an emergency contact.
Does an FNJ-built site need FNJ to keep running after handoff?
No. FNJ does not host the site, and the exported code contains no FNJ runtime, script or badge, so the site keeps working on the client's own hosting.