Who Should Own Your Website? Domain, Hosting, Code and Accounts Before You Hire a Designer

Paying for a website does not answer the most important ownership question: what will your business actually control when the project is finished?

A modern website is not one asset. It can involve a domain registrar, DNS, hosting, a CMS, a code repository, analytics, forms, email delivery, payment accounts, databases and third-party licences. Those pieces can sit in different accounts and carry different legal rights.

Before you hire a web designer, decide who will own or control each one. The goal is not to distrust the person building the site. It is to make the commercial relationship clear enough that changing providers later is an ordinary handover, not an emergency recovery project.

The simplest ownership rule

For infrastructure your business depends on, the safest default is:

your business owns the account; your designer receives the access needed to do the work.

That is different from sharing your password. Good platforms increasingly support members, collaborators or delegated roles. Cloudflare, for example, lets account administrators add members with scoped policies rather than handing over the primary login: Cloudflare account-member documentation.

Some arrangements legitimately differ. An agency may provide managed hosting. A proprietary website platform may license rather than transfer its underlying software. A developer may retain reusable components while assigning the custom work created specifically for you.

Those are commercial choices. The problem begins when nobody explains them until you want to leave.

1. Your domain should not be an afterthought

Your domain is the address attached to your brand, website and often your business email. Your business should know:

• which registrar holds it;
• which business-controlled email can recover the account;
• who is listed as the registered name holder where applicable;
• who receives renewal notices;
• who can unlock or transfer it.

ICANN’s current Transfer Policy says the Registered Name Holder is the party with authority to approve or deny an inter-registrar transfer. That is why domain control is more important than simply knowing who paid the renewal invoice: ICANN Transfer Policy.

A designer can configure DNS without becoming the long-term holder of your domain.

2. Separate domain ownership from DNS and hosting

These are related, but they are not the same thing.

The domain registrar records and renews the domain. DNS tells browsers and email systems where services live. Hosting or deployment runs the website itself.

One company may provide all three, but they can also be split across different providers.

That distinction matters during a handover. Moving a website to another host does not necessarily require transferring the domain to another registrar. If the domain remains under business control, a new technical team can often change the relevant DNS records while leaving registration untouched.

Before paying a deposit, ask where each layer will live and who will hold the highest level of access.

3. Hosting can be managed without becoming a trap

There is nothing inherently wrong with a designer or agency offering managed hosting. You may prefer one invoice and one person responsible for uptime, deployment and maintenance.

But managed hosting should answer four questions in writing:

1. Can I obtain a current export or backup of the site and its data?
2. Can another qualified provider move the site later?
3. What happens to hosting if the maintenance relationship ends?
4. Are migration or exit fees defined in advance?

The red flag is not “my designer manages hosting.” The red flag is “I cannot find out where my website lives or what happens if we stop working together.”

4. Code ownership is a contract question

Do not assume that “I paid for the website” means every line of software becomes your intellectual property.

A custom project can contain several layers:

If a custom website uses GitHub, repository ownership is technically transferable. GitHub’s documentation explains that a repository can be transferred to another user or organisation, with its Git history and many associated resources preserved: GitHub repository transfers.

The important part is agreeing whether that transfer is part of your project, not discovering the question after launch.

5. Own the operational accounts around the website too

A website can remain technically online while the business loses control of the systems that make it useful.

Depending on the project, identify the owner of:

• CMS administrator access;
• analytics and Search Console;
• business email and form-delivery services;
• payment processor or ecommerce account;
• booking or CRM system;
• database and authentication project;
• image or file storage;
• advertising pixels and tag manager;
• backups;
• API and integration accounts.

For anything connected to money, customer data, historical analytics or account recovery, business-controlled ownership becomes especially important.

6. Do not confuse access with ownership

A common mistake is believing you control an asset because somebody gave you a login.

Ask a stronger set of questions:

• Can my business reset the password without the designer?
• Can we change or revoke the designer’s access?
• Can we update billing and renewal details?
• Can we add another administrator?
• Can we export our content and data?
• Can we transfer the asset if the provider changes?

If every critical action still requires the designer’s personal account, you have access, but you may not have practical control.

7. The pre-payment website ownership checklist

Before paying for a business website, get clear written answers for these items:

You do not need to demand one technical setup from every designer. You need to understand the setup you are buying.

8. Use the “designer disappears tomorrow” test

A useful ownership audit is to imagine that the person who built the website becomes unavailable tomorrow.

Could your business still:

• renew the domain;
• keep business email working;
• access the website admin;
• see enquiries;
• access customer or order data;
• pay the hosting bill;
• recover the account;
• give a new provider access;
• obtain the code or export promised in the contract;
• restore from a backup?

If the answer is no to several of those, fix the ownership structure before the website becomes more valuable.

This is one reason I prefer designing the account and handover model as part of the website itself, not treating it as paperwork after launch. A website should remain a business asset even when the people maintaining it change.

Ownership does not mean doing everything yourself

Owning your accounts does not mean you need to manage DNS, deployments or backups personally.

You can still pay a specialist to handle those jobs. The difference is that the specialist works inside infrastructure your business can recover and reassign, rather than becoming the only person capable of accessing it.

That creates a healthier relationship for both sides: the designer is retained because the work is valuable, not because leaving is technically painful.

If you are comparing proposals, my web design service explains how I approach business websites. If you already have a site but are unsure who controls the domain, hosting, code or connected accounts, contact me and I can help you map the current setup before you change anything.

Sources

• ICANN Transfer Policy
• GitHub: Transferring a repository
• Cloudflare: Manage account members