Why we hand over the domain, code and accounts

Hernán Capucci — Fri, 16 Oct 2026 16:45:13 +0000

A website has a visible part and an invisible part. The visible part is what people see when they open the address: pages, type, images. The invisible part is everything that makes those pages exist and keep existing: the domain, the hosting, the code, the files, the accounts, the passwords and the order in which all of that was set up.

Most conversations about a new site are about the visible part. That makes sense; it is the part you can judge by looking. But whether a site is really yours is decided almost entirely by the invisible part. This post is about that part: what owning a website actually means, where people lose control without noticing, and what anyone should receive when a project ends — whoever builds it.

Ownership is a list of things, not a feeling

"It's your website" is easy to say. It becomes true only when a short list of concrete things is in your name, or at least under your control.

The domain

The domain is the address, and it is the one piece that is hardest to replace. You can rebuild a site. You can move hosting. Changing the address means changing every link, every printed card, every profile and every search result that points to it.

So the domain should be registered in your name, with the registrar login in your hands or the transfer process documented. A domain registered in the account of whoever built the site, "for convenience", is the most common way people end up not controlling their own presence. Nothing goes wrong on the first day. It goes wrong two years later, when the renewal email reaches someone else, or when you want to change providers and discover the address is not yours to move.

The hosting and the deploy

You should know where the site lives, how to get into that account and what it costs. If the site is deployed from a repository, you should know which one, and how a change gets from the code to the live address.

Hosting inside someone else's account is not a problem in itself; plenty of people prefer not to manage it. It becomes one when you have no access at all, no documentation and no way to leave. The question to ask is not "who hosts it?" but "could I move it without asking anyone's permission?"

The code and the files

The code, the build configuration, the images in their original quality and the text of the site are the material any other developer would need to continue the work. If they only exist inside a builder you don't control, or on someone's laptop, the next person has to rebuild from what they can see in a browser.

Receiving the files or the repository does not mean you need to read them. It means that if you ever change hands, the next person starts where the last one stopped.

The accounts

A website quietly creates accounts: the registrar, the hosting, the DNS provider, an email service, analytics, Search Console, a form service, maybe a map key or a font licence. Each of them is a small dependency.

What you need is a map: which accounts exist, what each one is for, which email it is registered to, and who can get in. Without the map, even a site whose every account is technically yours is hard to run, because nobody remembers what the form service was called.

Security and recovery

Two-factor authentication on the accounts that matter, and notes on how to recover them, are part of the deliverable. An account you own but can't recover is only slightly better than one you don't own.

How lock-in actually happens

Lock-in is rarely deliberate. It is usually the sum of small shortcuts:

registering the domain in the builder's account because it was faster;
deploying from a personal repository "for now";
creating analytics under an agency email;
leaving the only admin login with the person who built the site;
delivering a link to the site, but not the site.

Each shortcut saves a few minutes during the project. Together, they mean that every later change — a new provider, a small edit, a renewal — has to go through one specific person. That is a dependency nobody chose.

There are good reasons to work with the same studio for years. Being unable to leave is not one of them. A healthy arrangement is one you could end on a Tuesday and still have a working website on Wednesday.

What a client should receive at the end

A useful test is: if the person who built the site disappeared tomorrow, could someone else take over with what you were given? In practice, that means receiving:

The domain, in your name, with registrar access or the transfer documented.
Hosting details: where the site lives, how to log in, what it costs.
The site files or repository, complete enough to rebuild and redeploy.
A map of accounts and access: every account the project created, what it is for, who controls it.
Security and recovery notes, with two-factor enabled where it matters.
The content: the text, organised and editable outside the site.
The images and media, also in original quality.
Search basics, explained: structure, metadata, sitemap — and what they do and do not promise.
Search Console and analytics in your own accounts, so the data about your site is yours.
A clear statement of what happens after delivery: what maintenance exists, what it covers, where it stops.
The steps to revoke the builder's access once everything is handed over.

None of this requires technical knowledge from the client. It requires that it is written down, in plain language, and handed over.

Why we work this way

At OwnSite Studio every project ends with a handoff: the domain, code, files and accounts stay in the client's name, and the project closes with a folder and a document that cover the list above. Maintenance is an option, not a condition: a client can keep everything and run the site themselves, with the handoff document as the manual.

We do it for a simple reason. A website is supposed to be an asset for the person who paid for it. If it only works as long as one provider stays involved, it is closer to a subscription than to an asset — and nobody signed up for that.

We also published the full checklist, written so it's useful whoever builds your site: Website handoff checklist.

If you're about to start a project with anyone, ask for that list before the first design. The answer tells you a lot.

OwnSite Studio — custom websites, made around each project.
https://ownsitestudio.com

DEV Community: OwnSite Studio