Ask a client who owns their website and they will almost always say, “I do, I paid for it.” Ask the developer who built it and you often get a slower answer. The domain is in my account, because I set it up. The hosting is on my plan, because it was easier. The code is in my repository. The analytics is under my email.
Both people are being reasonable, and they are describing the same website. The trouble is that a website is not one thing. It is a handful of separate things, and each of them can have a different owner without anyone ever deciding it.
Most of the time this never matters. Then the developer changes email address, gets ill, stops freelancing, or the two of them fall out, and the client discovers that their business sits behind a login they have never seen.
A website is six things, not one
It helps to pull the website apart and ask who holds each piece.
The domain is the address, such as yourbusiness.com. It is registered with a registrar, and whoever owns that account controls where the address points, and whether it renews.
DNS is the set of records that connects the domain to the website, to email and to other services. It usually lives with the registrar or with whoever manages the domain, and a wrong change can take a site or an inbox offline.
Hosting is where the website actually runs. It might be a hosting plan, a platform account, or a server. If the site is unpaid or the account is closed, the site goes down.
The code and files are the website itself: the source, the images, the build setup. These often sit in a repository such as GitHub, and also in the developer’s own folders.
The content is the words, photos and product details that belong to the business. Even when the code is the developer’s work, the content is the client’s.
The connected accounts are everything around the edges: analytics, search console, the email service that sends the contact form, payment providers, map keys, tag managers. These are the ones people forget, and they are the hardest to recover later because they were set up one at a time over months.
The rule that prevents most problems
A simple rule covers nearly all of it. The client should own the accounts, and the developer should be invited into them.
That means the client registers the domain, or you register it under their name and email and transfer it. The client holds the hosting account, and you are added as a collaborator. The client owns the analytics property and adds you as a user. The reverse, where you own everything and lend access to the client, feels convenient on day one and becomes a liability on day five hundred.
This is better for you as well as for them. If you own the client’s domain, you are on the hook for renewing it. If it lapses, it is your name on the problem. Holding a client’s accounts also means holding their risk, their bills and their support requests, usually without being paid for any of it.
Four situations where ownership comes up
The first is the unpaid or lapsed renewal. Domains and hosting renew on a schedule, and the reminder emails go to whoever registered them. If that is a developer’s old address, nobody sees it. Put renewal reminders in the client’s inbox and, ideally, a second contact too.
The second is the developer who disappears. Illness, a career change or a closed business can all end a working relationship overnight. If every account is in the developer’s name, the client has to prove ownership to a registrar or host, which can take weeks.
The third is the relationship that ends badly. A website held hostage over a payment dispute is a nightmare for the client and a reputation risk for the developer. Clean ownership removes the leverage from both sides, which is exactly why it keeps things civil.
The fourth is the next developer. Sooner or later someone else will work on the site. If they need an hour of detective work to find where it is hosted and how it deploys, the client pays for that hour.
What to do on a new project
Do this at the start, when the client is feeling positive and nothing is at stake.
First, ask the client to create the domain and hosting accounts, or do it with them on a call. Use a company email address rather than a personal one, so the account survives a change of staff.
Second, invite your own login as a collaborator rather than using the client’s password. Most registrars, hosts, analytics tools and repositories support extra users. It keeps a record of who did what and lets either side remove access cleanly.
Third, keep a short ownership note. A page is enough: each piece, where it lives, whose account it is under, when it renews, and who to contact. This is the single most useful document you can hand over, and few people ever write one.
What to do on an existing project
If you have already built sites where you hold everything, you do not need to panic or announce a policy change. Go through your clients one at a time and list what you hold. Then offer to move things across: “I would like to make sure you have full ownership of your domain and hosting, so I’m going to help you set that up.” Most clients are glad to hear it, and many have wondered about it without knowing how to ask.
Do the domain first, since it is the piece that is hardest to replace. A transfer usually involves unlocking the domain, passing an authorisation code to the new owner and waiting for the registrars to confirm, so allow a few days and do not do it in the middle of a launch.
Offboarding is part of the job
When a project ends, or a relationship does, remove yourself properly. Hand over anything still in your name, take your access off their accounts if they want you to, and send a closing note that says where everything is. Leaving a client with clean ownership is the strongest thing you can do for the next conversation, whether it is a referral or a new project.
Where Baton fits
Baton is built around this split. The client gets a place to edit the content that is theirs, such as text, images and selected visual properties, while you keep the structural work you are paid for. It does not replace the ownership note, though. Whichever tools you use, settle who owns the domain, the hosting and the connected accounts at the start, and write it down. It takes thirty minutes now and saves a very uncomfortable email later.