Who owns your website? What to check before you sign

Nobody thinks much about who owns a website until something changes. Your developer moves on, the agency that built the site closes, or you want to change something yourself and find you can't sign in to anything. That's when it matters whose name is on each account.

A website is several things: a domain name, a hosting account, the code, your data, and the services that take payments and send email. Here is who should hold each one, and how to check. If you're changing developers, see what a good website handover includes.

The domain name

Your domain is the address customers know, and the hardest piece to replace. The registrar is the company you register it through. The registrant is the person or business that holds it (ICANN explains the difference). The registrant should be your business, and you should have your own login to the registrar account.

Paying for a domain doesn't make you its registrant. ICANN's compliance FAQ notes that a developer may have registered it with their own details even when you paid for it.

To check, look the domain up with ICANN's free lookup tool, which uses RDAP, the successor to WHOIS. It shows the registrar and the expiry date. The registrant's details may be redacted, so the dependable check is inside the registrar account: whose name and email address are on the registration? Make sure that email is one your business reads. For .com and other generic domains, registrars must send the registrant renewal reminders about a month and a week before the domain expires. Then turn on auto-renew and keep the card on file current.

The hosting account

The hosting account is where your site runs, and whoever holds it can change the site or switch it off. It should be in your business's name and on your billing, with your developer invited in as an administrator, not the other way around.

If your site runs on Firebase, its project is a Google Cloud project, linked to a Cloud Billing account that defines who pays. That billing account should be yours. Billing access is managed separately, so an administrator on your project isn't automatically one on your billing.

To check, open the IAM page in the Google Cloud console, which lists everyone with access to the project and their role. Someone at your business should hold the Owner role, which controls who else gets in. The Billing section's My Projects page shows which billing account pays. With any other host, ask the same: whose name is on the account, and whose card pays?

The code

Ask where the code will live. On GitHub, for example, it lives in a repository that keeps its full history: every version of every file. It's reasonable for a developer to keep yours in their own GitHub organization while they work on the site, as long as you have read access. A full copy, called a clone, includes that history, and GitHub can transfer a repository to your own account with its history intact. Ask when, and on what terms, that happens.

Ask what it's built with, too: standard, widely used technology can be picked up by another developer. Some website builders run only on their own servers: your content may be yours, but the site itself can't move to another host. That can be a fair trade, as long as you know it going in.

Then read the contract, because paying for the work doesn't by itself settle who owns it. Under US copyright law, the person who creates a work is ordinarily its author. Commissioned work counts as a “work made for hire”, which makes the client the author and owner, only in specific categories and with a signed written agreement saying so (see the US Copyright Office's circular on works made for hire). Look for a clause on who owns the code once it's paid for, or what license you get, and what the developer keeps. If the wording isn't clear, ask a lawyer.

Your data and content

Your content is your words, photos and documents. Your data is what the site stores: the database, uploaded files, customer records, orders and form submissions. All of it should sit in an account you own. Ask where each kind is kept, whose account that is, and how you would export it. A good answer names a format other systems can read, such as spreadsheet files for records and the original files for uploads. Whoever holds an account can read what's in it, so ask who can see customer information too.

Payment, email and analytics accounts

The services around your site each have their own account, and each should be in your business's name.

• Payments. If you take payments with Stripe, the account should belong to your business, with payouts to your bank account. Stripe asks whoever opens an account to verify the business and their relationship to it, and recommends adding other people as team members rather than sharing a password. Each account has one owner, and only the owner can transfer ownership, so the owner should be you. A developer can be invited with the Developer role.
• Email sending. The service your site sends form notifications and order confirmations through should be in your name too.
• Analytics. In Google Analytics, only the Administrator role can add and remove users, so that role should be yours.

Admin access

Finally, list every account the site depends on and who can sign in to each. Everyone should have their own login, invited by the account holder, instead of a shared password. The account holder should be your business, using an email address it controls, not one person's personal login. If the only way in belongs to an employee who has left or a developer you no longer work with, you're back to asking for access to your own site. Turn on two-step verification wherever it's offered.

Questions to ask before you sign

• Whose name will the domain be in, and will I have my own login to the registrar?
• Whose account will the site run in, and whose card pays for it?
• Where will the code live, can I see it during the build, and how do I get a full copy?
• What does the contract say about who owns the code, and what do you keep?
• Could another developer take the site over?
• Where will my data be stored, and how would I export it?
• Will the payment, email and analytics accounts be in my business's name?
• If we part ways, what do you hand over, and is there a fee?

They're fair questions for any developer, us included.

Warning signs

None of these proves bad faith, but each is worth settling before you sign.

• The domain is registered to the developer, or you've never had a login to the registrar.
• The site only runs on the developer's own platform and can't be moved.
• Nobody can tell you how you would export your data or content.
• The contract gives you no right to take the code elsewhere, or doesn't mention it at all.
• Every account sits under the developer's login.
• A handover fee that isn't in the contract.

How we handle it at Titus Apps

Your site runs in a Google Cloud project on your own billing account from day one, with us invited in as administrator, so Google bills you directly. Your domain and your email-sending account are in your name, and so is your Stripe account if you take payments.

The code lives in our GitHub organization while we manage your site. You have read access from day one, and once the build is paid for, we transfer the repository to your GitHub, free, whenever you ask. Hosting and ownership explains what we can access while we manage your site, and how leaving works.