Should the client own the domain or should I hold it for them?

The client should own it, registered in their own name with their own email on the account. A domain held in a developer's account is the single most common reason a small business loses control of its own web presence years later. If they want you to manage it day to day, get added as a user on their account instead of putting the registration in yours. It costs you nothing and it removes the worst argument a former client can ever have with you.

What if the client cannot manage the accounts themselves?

Then sell them a maintenance arrangement, in writing, with a scope and a price. That is a legitimate service and it is very different from silently keeping the keys because it was easier at launch. The distinction matters when the relationship ends. Ownership sits with them, access sits with you by agreement, and either side can end the arrangement without the site going dark.

Do I have to hand over the source code?

It depends entirely on what you agreed before you started, which is why it should be written down before you start. Custom work is commonly transferred outright. Work built on a template or a base you reuse is commonly licensed rather than transferred, because you cannot give away rights to something you resell. Either is honest. What is not honest is leaving it undefined until the client asks for the files.

How long should I support a site after launch?

Pick a defined window, say it out loud, and put it on the handoff document. A common shape is a short period covering anything that is genuinely broken, then a separate paid arrangement for changes. The reason to define it is not that clients are unreasonable, it is that an undefined window quietly becomes forever and then ends badly.

What is the one thing most handoffs forget?

Where the lead form actually sends its messages. It is set up once during the build, usually with the developer's own account or key, and nobody checks it again. Months later the form fails, or the account it points at gets closed, and the business loses jobs without ever knowing a message was sent. Test it with a real submission at handoff and make sure the destination inbox belongs to the client.

Website Guides

How to Hand Off a Website to a Client Without Leaving Yourself on the Hook

A website is not delivered when it goes live. It is delivered when the client owns everything it depends on, knows where it is, and can keep it running if you disappear tomorrow.

Most handoffs skip that second part. The site launches, the invoice goes out, and six accounts stay quietly in the developer's name. That is fine right up until it is not: the client wants to move, or you get busy, or an email address stops existing, and suddenly a working business is locked out of its own front door.

This is the checklist we use. It is written for the freelancer or small agency delivering a site to a local business owner who is not technical.

The seven things that have to change hands

1. The domain registration. This is the one that matters most and it is the one most often gotten wrong. The domain should be registered in the business's name, on the business's own account, with an email address the business controls. Not yours. If you registered it during the build because it was faster, transfer it before you invoice the final payment, while you are still in contact and it is still easy.

2. DNS control. Related but not the same thing. Domain ownership is who holds the registration; DNS is who decides where the name points. Whoever controls DNS can move the site, and can also break the email. Note in writing which service is answering for the domain and who has a login to it.

3. The hosting or deploy account. If the site sits on a platform account in your name, the client's site lives inside your billing relationship. Either move the project into an account they own, or state plainly that hosting is part of an ongoing service you provide and price it. Both are fine. What is not fine is neither, and the three workable arrangements are laid out in how to host client websites.

4. The code. Where it lives, who can read it, and what the client is allowed to do with it. If the site is built on a template or a base you reuse across clients, say what is transferred and what is licensed. See website templates for client work for the licence question in detail. For a worked example of what a transferable template licence actually says, ours is published at the Site Kit licence.

5. Where the lead form sends messages. The most-forgotten item on the list and the most expensive one to get wrong, because failure here is silent. Confirm the destination address belongs to the business, send one real test submission at handoff, and write down what the fallback is if the sending service ever fails.

6. Analytics. If a measurement property exists, it should be owned by the business with you added as a user, not the reverse. Nothing is more awkward than telling a former client that their traffic history left with you.

7. The Google Business Profile. Not part of the website, and more important to the phone ringing than the website is. It must be owned by the business owner with you added as a manager. Never the other way round. The reasons this listing carries so much of the local result are in the guide on Google Business Profiles for contractors.

The handoff document

One page. Written for someone who will read it in a year, in a hurry, possibly after you are unreachable.

Every account, what it is for, and whose name it is in
Where the domain is registered and where DNS is answered
How to change the phone number, the hours and the service areas, in the specific way this site does it
Where form submissions arrive and how to test that they still do
What is covered after launch, for how long, and what costs money
Who to call, which may not be you forever

If the site is config driven, this document is short, because "change the phone number" is one line in one file rather than a tour of eleven pages. That is a real argument for building that way when the client is not technical.

The conversation nobody wants to have

Say what happens after launch, before launch. A defined window for genuine defects, then a stated arrangement for changes, at a stated price. Put it in the proposal.

Undefined support is not generosity. It is a slow leak that turns a profitable project into a resented one, and it makes the eventual boundary feel like a betrayal to a client who was never told there was one. If you are working out what those numbers should be, what to charge to build a small business website covers the pricing side.

Why this is a sales asset, not just admin

A one-page handoff document that says "you own this, here is where everything is, here is how to change your own phone number" is a genuinely uncommon thing for a small business owner to receive. Most have been burned once, and many will tell you so if you ask.

Owning the thing you paid for is the argument behind Wix versus owning your website, and it is worth making out loud at the end of a project rather than assuming the client noticed.

Our version of this

Every Service Site Kit ships config driven for exactly this reason: business name, phone, hours, services and service areas live in one settings file, so the "how do I change something" section of a handoff document is a paragraph rather than a manual. Each kit includes a launch guide written for the non-developer who will end up owning the site.

If you are taking over a site somebody else built, the two pages worth reading first are who owns your website, for working out which accounts the client actually controls, and how to switch website providers without going dark, for the order of operations that keeps them online through the move.

Common questions

Should the client own the domain or should I hold it for them?: The client should own it, registered in their own name with their own email on the account. A domain held in a developer's account is the single most common reason a small business loses control of its own web presence years later. If they want you to manage it day to day, get added as a user on their account instead of putting the registration in yours. It costs you nothing and it removes the worst argument a former client can ever have with you.
What if the client cannot manage the accounts themselves?: Then sell them a maintenance arrangement, in writing, with a scope and a price. That is a legitimate service and it is very different from silently keeping the keys because it was easier at launch. The distinction matters when the relationship ends. Ownership sits with them, access sits with you by agreement, and either side can end the arrangement without the site going dark.
Do I have to hand over the source code?: It depends entirely on what you agreed before you started, which is why it should be written down before you start. Custom work is commonly transferred outright. Work built on a template or a base you reuse is commonly licensed rather than transferred, because you cannot give away rights to something you resell. Either is honest. What is not honest is leaving it undefined until the client asks for the files.
How long should I support a site after launch?: Pick a defined window, say it out loud, and put it on the handoff document. A common shape is a short period covering anything that is genuinely broken, then a separate paid arrangement for changes. The reason to define it is not that clients are unreasonable, it is that an undefined window quietly becomes forever and then ends badly.
What is the one thing most handoffs forget?: Where the lead form actually sends its messages. It is set up once during the build, usually with the developer's own account or key, and nobody checks it again. Months later the form fails, or the account it points at gets closed, and the business loses jobs without ever knowing a message was sent. Test it with a real submission at handoff and make sure the destination inbox belongs to the client.

We build Service Site Kits for exactly this: a complete, ready to launch website for one trade, $99 once, yours to keep.

See the Site Kits →

Kit checkout is closed while we move to a new payment provider. The thinking behind every kit is in the book, and that you can buy today: Small Town Strategy (paperback $14.99, Kindle $6.99).

Want to know where your own site stands?

Paste your address into the free website check and get 18 plain-English findings in about ten seconds. No email, nothing saved.

Check my website

Get new guides by email

Short lessons on websites, Google, reviews and word of mouth, in plain English. Free, unsubscribe any time.

Or have somebody else do it

Most of what is on this page you can do yourself in an afternoon, and plenty of people should. If you would rather not, we rebuild the site, fix the Google listing that usually matters more, and keep working on both. $500 a month, 12 months, the build included, nothing up front, and the domain and the listing stay in your name.

What that involves Ask a question Check my site free