Handing a finished site to the client who paid for it

What you hand over, in five items

The question usually arrives in a friendly voice, halfway through a call about something else. So what happens if we stop working together. If you cannot answer that in one breath, the handover has not been built yet, and you will assemble it in a hurry on the worst possible week.

Here is the whole answer. Everything after this section is detail on how each piece moves.

• 1. The repository. The source code, sitting in a Git account the client controls rather than one you control.
• 2. The deploy account. Whoever holds the hosting account is the only person who can push the next change to it.
• 3. The domain registrar login. Not the DNS records — the account the name itself is registered in, with the client as the registrant.
• 4. Where the contact form sends. The inbox, address or endpoint on the far end of that form, written down somewhere other than your head.
• 5. Where the images came from. Every photo, its source, and what the client is permitted to keep doing with it.

Note. The contact form is the item that fails quietly. Nothing errors, no page breaks, and six weeks later the client asks why nobody has rung them — because the form has been posting to an address that belongs to you.

How the code actually leaves Grafter

There are three routes out and they all carry the same files. Download the whole project as a zip, or push it to your own GitHub or Vercel account.

The GitHub push is private unless you say otherwise. The server treats the repository as private unless the request explicitly asks for a public one, and the reason is written into the code beside it: nobody should discover that their client's half-built site was public by default. On client work that default is doing real work for you. A repository named after the business, carrying their prices, their draft copy and their address, indexed six weeks before they have agreed to any of it, is a phone call you never want to take.

The Vercel route sends the same files into whichever Vercel account the token you paste belongs to. Grafter is not the host and holds nothing afterwards. That token decides who gets the hosting account, who gets the bill and who has the button that ships the next change, so it is worth deciding whose account that is before you use it rather than after.

The zip is the one to reach for when the client already has a developer, or an internal system, or an opinion about where code lives. It is a folder, and it goes wherever they want folders to go.

Export to GitHub or Vercel sits on the free tier, not behind a paid plan. That is worth knowing on the day a client wants to hold their own copy without opening an account on a plan they will never use again.

• Push to GitHub — private unless you set it otherwise, into the account the token belongs to.
• Deploy to Vercel — the same files, into the Vercel account the pasted token belongs to.
• Download the zip — the same project as a folder, for a developer who wants it in their own system.

The handover is the deliverable

A client who receives the repository, the domain and the deploy account owns the site, and you stop being their support desk. A client who receives a URL and a thank-you owns a relationship with you instead. That is a different product, and if you are selling it you should be charging monthly for it rather than absorbing it.

It helps to say out loud where the three things actually live, because none of them live in Grafter. The domain sits at a registrar. The hosting sits in a Vercel account, or wherever else the built files were put. The repository sits at GitHub. Grafter wrote files into two of those places once, when you asked it to, and has no continuing hold on any of them.

Which means the transfers happen in those tools and nowhere else. You move a repository in GitHub's own settings, and the receiving account has to accept it. You move a project in Vercel, from the account that holds it. You move a domain at the registrar, with an auth code and a wait. There is no button inside Grafter that does any of this, and there is no route that moves a project from your account into somebody else's.

The practical version: do the transfers while the client is still on the call. Every one of them needs somebody at the other end to click accept, and an email asking a busy person to accept a GitHub repository transfer can sit unread until the invitation expires. Two minutes on a call beats a fortnight of reminders.

• Repository — transferred in GitHub, accepted by the receiving account.
• Hosting — transferred in Vercel, or rebuilt from the repository in the client's own account.
• Domain — moved at the registrar, or left where it is with the client made the registrant.
• The form's destination — changed in the code, then confirmed by sending a real test message.

Note. If you sell a retainer and want the hosting, the billing and every edit to stay in your own account, hand none of this over — the whole page is a list of ways to lose recurring revenue you have deliberately built. That is a legitimate business. Just decide it on purpose, price it, and tell the client which one they bought.

What Grafter does not do for you here

Worth being blunt about, because a handover plan built on a feature that does not exist falls over in front of the client. There is no white-label mode. There is no client login, no read-only seat and no way to show somebody the build history without handing them your own account. There is no per-client billing: your card pays for every build on your account, whoever the work is for, and you cannot put a project on a client's card.

Studio is $299 a month and Agency starts at $399, both written for people who build sites for other people. What those tiers actually contain is credits, how many builds can run at once, how many an hour, and the support you get. That is the complete list. They are not a reseller programme, they do not change anything the client sees, and nothing about them makes a project belong to somebody else.

One small thing that catches people on the day. The project the client receives is a runnable Vite project rather than a pile of components, because the server fills in the shell — package.json, vite.config.js, index.html, a gitignore and a README — wherever the build did not write those files itself, and anything the build did write wins over the shell. So the developer at the other end runs npm install and npm run dev and it starts. That README says the site was built with Grafter. If you would rather it did not say that on a repository with your client's name on it, change the line before you push.

• No white-label mode. The scaffold README names the tool until you edit it.
• No client login, no read-only seat, no shared build history.
• No per-client seat and no way to bill a client through Grafter.
• No route that moves a project from one Grafter account to another.

Doing it on the day, in order

The sequence matters less than doing it in one sitting, but this order has the fewest dead ends. Build in your own account, push to your own GitHub while the work is in progress, and transfer once at the end. The alternative — talking a non-technical client through creating a personal access token so the push lands in their account first — is a twenty-minute phone call that teaches them nothing they wanted to know.

Before you transfer anything, spend ten minutes making the repository readable by someone who was not there. A plain text file listing where each photo came from, one line each. A line saying where the contact form posts and who reads it. The name of the registrar and the account the domain is under. None of that is glamorous and all of it is the difference between a handover and an abandonment.

Then send one real test message through the form after the transfer, from a phone, and have the client confirm it arrived on their side. Do not take the form's word for it. It is the only item on the list that can look completely fine while being completely wrong.

The contract is the other half of this and it is not a matter a website builder decides. What ownership means, what happens to the design, what you are allowed to show afterwards and who carries the cost when something breaks in month four — that belongs in writing before the invoice, and it is worth having someone who does this for a living read those clauses once. There is separate writing on this site about terms and what to put in them. Neither that nor this page is legal advice.

Last, decide what happens to the project sitting in your own Grafter account. Handing over the code does not remove it, and every build you run in it afterwards is still spending your credits. Either agree that you keep it and keep charging for changes, or agree that the client takes the site into an account of their own and stops needing you for a price change on a Tuesday.

• Rename anything still carrying your studio's name — the project, the repository, the deployment.
• Replace the README line if the client's repository should not name the tool.
• Transfer the repository, and watch the client accept it.
• Move or rebuild the deployment in the client's own hosting account.
• Make the client the registrant on the domain, and turn auto-renew on.
• Send a real test message and have the client confirm it arrived.
• Hand over the list of image sources, in writing.

Common questions

If I hand over the code, why would they ever pay me again?

Because almost nobody who commissions a website wants to edit one. What you are handing over is the ability to leave, not the appetite to. Clients who can go elsewhere and stay are worth more than clients who stay because they are stuck, and the second kind tend to leave loudly the moment somebody explains to them that they were. Sell the next thing on its merits — a seasonal page, new photography, a rewrite when the prices change.

Does the client need their own Grafter account?

Not to receive the site. The repository, the domain and the hosting account are theirs regardless, and none of them depend on Grafter afterwards. They only need an account if they want to keep changing the site by describing changes rather than by editing code. The free tier grants 3,000 credits a month, a full site generated and browser preview, which is enough to see what that feels like. Paid plans start at $20 a month, or $16 a month paid yearly.

What if they break it and blame me?

Two defences, and both are cheap. The first is Git: once the repository is in their account, every change is a commit and the state you handed over is still in the history. The second applies while it is still in a Grafter account — every build turn is snapshotted before it runs, and reverting is itself revertible. Say plainly, in writing, what happens after the handover: whether you fix things, at what rate, and for how long.

Who owns the design?

That is settled by your contract with the client, not by the tool the site was built in, and the two are worth keeping separate in your head. Handing over the repository is a practical act — it transfers control, not necessarily rights. If you want to reuse a layout across clients, or the client wants exclusivity over what they paid for, that is a sentence in the agreement rather than something you sort out at the point of export.

Can I keep a copy for my portfolio?

Agree it before you hand over, not after. It costs nothing to ask while the client is pleased with you and it is awkward to ask a year later. Keep the zip and a set of screenshots on the day, because the site that exists in eighteen months will not be the one you designed — the client will have changed the prices, added a page and swapped a photo, which is the entire point of handing it over.

What should the contract actually say about this?

In plain terms, it should name who ends up holding the domain, the hosting account and the repository, what happens to the work if the project stops halfway, what you may show afterwards, and what support if any is included after handover. Do not draft that from an article, this one included. Write down what you actually intend, then have someone qualified turn it into clauses — it is an hour of somebody's time against a dispute you cannot win by email.