Who should own your hosting, domain and code

You. The short answer is you, for nearly all of it. The longer answer is a checklist, because "the website" is really a dozen separate accounts, and each one is in somebody's name.

How it goes wrong

The usual story goes like this. A developer sets things up quickly, in their own accounts, because it's easier at the time. The domain is registered with their login. The hosting is on their card, and they bill you for it. The code lives in their repository. Nothing about this is sinister. It's convenient.

Then something changes. They get busy, move on, fall ill, or you simply want someone else. Now you need their cooperation to move your own business's website. If the relationship has soured, or they've vanished, you can lose the domain your customers know, the email that runs on it, and every line of code you paid for.

None of this needs bad intent to happen. It just needs nobody to have thought about it at the start.

The accounts that should be in your name

Go through this list. For each line, ask: whose login is it, whose email gets the renewal notices, and whose card is on file?

• Domain registrar. The account where your domain is registered. This is the most important one. Whoever controls it controls your website and your email.
• DNS. Often the same as the registrar, sometimes a separate service. It's what points your domain at your hosting and your email provider.
• Hosting. Where the site or app actually runs.
• Code repository. GitHub, GitLab or similar. Ideally an organisation in your business's name, with your developer added as a member.
• Business email. Google Workspace, Microsoft 365, or whatever you use.
• Email sending service. If your site or app sends notifications, there's often a separate account for that.
• Payments. Stripe or similar. This one should never be in anyone else's name; it's where your money lands.
• API keys and third-party tools. Your accounting software, maps, booking tools, analytics, anything the system connects to.
• Backups. Where they're stored, and who can get them back.
• Password manager. A shared vault in your business's account where all of the above live.

Your developer needs access to most of these to do the work. Access is fine. Ownership is the point.

How to check today

This takes an afternoon at most.

1. Find your registrar. Search your inbox for your domain name plus "renewal". Whoever receives those emails is effectively in charge of the domain. If it isn't you, that's the first thing to fix.
2. Log in. For each account above, try to log in yourself, with your own credentials. If you can't, write down who can.
3. Check the billing. Whose card pays for hosting and the domain? If you're paying your developer a "hosting fee" rather than the host directly, ask which account it's on.
4. Check the repository. Ask for a link to the code. Can you see it? Is it in an account you could add or remove people from?
5. Write it down. One page: each account, who owns it, who has access, where the login is stored.

If you find something in someone else's name, ask nicely for it to be transferred. Most registrars and hosts have a standard process for moving an account or a domain between owners. It's routine, and a decent developer won't mind.

What "you own the code" actually means

This phrase gets used loosely, so it's worth unpacking.

In my projects, after final payment, I assign you the copyright in the custom code I wrote for you. That's the code specific to your project: your screens, your workflows, your integrations.

What it doesn't cover:

• Open-source and third-party components. Almost every modern project is built on frameworks and libraries (Laravel, React and hundreds of smaller packages). Those stay under their own licences. Nearly all of them let you use, change and run them freely, but they're not yours to own, and they weren't mine either.
• A developer's own pre-existing tools. Many developers have their own small libraries or starter templates they reuse. With me, you get a permanent licence to use those as part of what I delivered; I just keep the right to use them elsewhere too.
• General know-how. I'll remember how I solved a tricky integration problem. That's not something anyone can hand over.

Before final payment, work in progress is for review and testing. That's normal, and it's fair to both sides.

Watch out for phrasing like "you own everything" or "100% yours" in anyone's sales copy. It's rarely accurate, because of the open-source point above. What you want is a clear sentence in the agreement about which parts are assigned to you and which are licensed.

What a good handover looks like

At the end of a project you should be able to tick all of these:

• The code repository is in your account, and you can see the full history
• Admin logins are in your password manager, not just the developer's
• Domain, DNS and hosting accounts are in your name, with your billing
• Every third-party account the system uses is in your name
• There's a README explaining how to deploy and how to run it locally
• You've exported your data at least once, and it opened
• You know when the developer's fix period ends, and what happens after

If you can do all of that, you're in a strong position. You can keep working with the same developer because you want to, not because you have to.

The new-project version

If you're about to start a project, ask these before you sign anything:

• Whose name will the domain, hosting and repository be in?
• What exactly is assigned to me at the end, and what's licensed?
• What will the handover include?
• What happens if you're unavailable for a month?

A developer who answers those clearly, in writing, is a developer worth considering. That includes me: the answers are on my project terms page, and in every proposal.