Website Ownership: Domain, Hosting, Content, and Source Code

When you hire someone to build your website, you own four things: the domain name, the hosting account, the content (text and images), and the source code. If any of those are in someone else's account or name, you do not fully own your website. Vendor lock-in happens when a developer controls one or more of these layers and you cannot leave without starting over.

This is the most common problem I see with small business owners. They paid someone to build a site, that person disappeared, and now the business owner cannot update their site, cannot access their domain, and cannot move to a new developer without rebuilding everything. This post explains how to avoid that.

For the specifics of how I handle ownership, see my terms and service scope.

The four layers of ownership

Layer 1: The domain name

Your domain name (yourbusiness.com) is the most important asset. If you do not control your domain, you do not control your web presence. Someone can take your entire site offline by pointing the domain elsewhere.

What you should own: The domain should be registered in an account with your name and your email on it. You should have the login credentials. You should be the registrant, not the administrative contact on someone else's account.

Red flag: Your developer registered the domain "for you" and it is in their GoDaddy or Namecheap account. If they stop responding, you have to file a domain transfer dispute with the registrar, which can take weeks.

How I handle it: I help you register the domain in your own account. I walk you through it if you have not done it before. The domain is yours from day one. I am listed as a technical contact if you want, but you are the registrant.

Layer 2: The hosting account

Hosting is where your website files live. The hosting account controls where the domain points and who can deploy changes to the site.

What you should own: The hosting account should be in your name with your payment method. You should have admin access. Your developer can have a collaborator or team member account, but you should be the account owner.

Red flag: Your site is hosted on your developer's personal server or their agency's hosting plan, and you have no access. If they go out of business, your site goes down with no warning.

How I handle it: For Gatsby sites, I deploy to Netlify. The account is in your name. I am added as a collaborator so I can deploy updates, but you can remove my access anytime. The billing goes to your card. If you stop working with me, you keep the account, the site, and the deploy history.

Layer 3: The content

Content is the text, images, videos, and any other media on your site. This is what your customers see and what search engines index.

What you should own: All content should belong to you. You should have copies of the original text files, the original image files, and the rights to use any stock photography. If you wrote the copy, you own it. If your developer wrote the copy, the contract should specify that the copyright transfers to you on payment.

Red flag: Your developer used stock images but did not give you the license information. Or they wrote your copy but the contract says they retain copyright. Or the content only exists inside the CMS and you have no offline copies.

How I handle it: You provide the content or I write it as a separate service. Either way, you own it. I send you the source files. For images, I use free-licensed stock or images you provide. If paid stock is used, I give you the license receipt. Everything is documented in the service scope.

Layer 4: The source code

The source code is the actual code that builds your website. For a Gatsby site, this is the React components, the MDX content files, the configuration, and the build scripts.

What you should own: You should have access to the full source code, not just the deployed output. This means a Git repository you can clone or download. If your developer built a custom theme or used a proprietary framework, you need to understand what you can and cannot do with it.

Red flag: Your developer will not give you the source code. They say "the site is hosted on our platform" and there is no way to export it. This is the most aggressive form of vendor lock-in. You are renting your website, not owning it.

How I handle it: The source code lives in a Git repository. When the project is done, I transfer the repository to your GitHub account or give you a full archive. The code is yours. If you hire a different developer later, they can clone the repo and take over. I use open-source frameworks (Gatsby, React) so any competent developer can work with the codebase.

Questions to ask before hiring anyone

Before you sign a contract or pay a deposit, ask these questions:

1. Will the domain be registered in my name? Get it in writing.
2. Will the hosting account be in my name? If not, what is the process to transfer it to you?
3. Do I own the content, including copy you write for me? Check the contract for copyright transfer language.
4. Will I receive the source code? In what format? When?
5. What happens if I want to switch developers? Is there a fee? A lock-in period?
6. What CMS or platform is the site built on? If it is a proprietary system, you cannot take it with you.
7. Can I export my content? If the answer is no, do not hire them.

If a developer dodges these questions or gets defensive, that is your answer. Move on.

How vendor lock-in actually happens

Vendor lock-in is rarely malicious. It is usually lazy. A developer registers the domain because it is faster than walking the client through it. They host the site on their own server because it is cheaper. They do not hand over the source code because it is easier to keep it in their own repo.

But the result for you is the same. When that developer stops responding, you are stuck. I have talked to business owners who lost their domain because a developer let it expire. I have talked to people who had to rebuild their entire site because the developer's hosting shut down and there was no backup.

The fix is simple: own your accounts from the start. It takes 20 minutes to register a domain and set up a hosting account. A developer who will not let you do that is not worth hiring.

How to verify you own your website

If you are not sure whether you actually own your website, here is how to check each layer in under 10 minutes.

Domain

Go to your domain registrar (GoDaddy, Namecheap, Google Domains, Cloudflare). Log in with your email. Do you see your domain listed? Is your name on the registrant contact? If you cannot log in, or the domain is not in your account, you do not own it. Call the registrar and ask who the registrant is. If it is your developer, you need to initiate a transfer.

Hosting

Log into your hosting account (Netlify, Vercel, Bluehost, SiteGround). Is the account in your name with your payment method? Can you see your site listed? If your developer logs in with their own credentials and you have no access, you do not own the hosting.

Source code

Ask your developer for the Git repository. If they say "it is on our platform" and cannot give you a repo you can clone, you do not own the source code. If your site is on WordPress, ask for an export of the database and a copy of the theme files. If you cannot get either, you are renting your site.

Content

Do you have the original text files and images somewhere outside the website? If the only copy of your content lives inside a CMS you cannot access, you do not fully own your content. Export it now.

What happens when you do not own your website

I have seen this play out three times in the last year.

A restaurant in northern Illinois had their site built by a freelancer who registered the domain in his own name. He stopped responding to emails. The domain expired. The site went down. The restaurant had to file a domain recovery dispute with the registrar, which took six weeks. During that time, their Google Business Profile pointed to a dead site.

A landscaping company had their site hosted on their developer's personal server. The developer got a full-time job and shut down the server. No warning. No backup. The company lost three years of content and had to rebuild from scratch.

A consulting firm had a custom CMS built by an agency. When they wanted to switch developers, they discovered the CMS was proprietary. No other developer could work with it. They had to rebuild the entire site on a standard platform.

In every case, the fix was the same: own your accounts from the start. The recovery is always harder and more expensive than the prevention.

How to transfer ownership if your developer holds the keys

If you are already locked in, here is how to get out.

Domain transfer: Ask your developer to unlock the domain and give you the authorization code (EPP code). Create an account at a registrar in your name. Initiate a transfer using the EPP code. If they refuse, file a complaint with the registrar. ICANN has a domain transfer dispute process. It is slow but it works if you can prove you paid for the domain.

Hosting migration: If your site is on a standard platform (WordPress, Gatsby, etc.), set up a new hosting account in your name, deploy the site there, and update your domain's DNS to point to the new host. If your developer will not give you the source files, you may need to scrape the live site and rebuild. That is painful but possible.

Content recovery: If you can still access the site, copy every page's text into a document. Download every image. If you cannot access the site, use the Wayback Machine at archive.org to recover older versions of your content.

Domain registration best practices

• Turn on auto-renew. Domains expire. If you miss the renewal email, someone else can grab your domain. Auto-renew costs nothing extra and prevents disaster.
• Enable domain privacy (WHOIS privacy). This hides your personal contact info from the public WHOIS database. Most registrars include it free now. If yours charges for it, switch registrars.
• Keep the registrar login somewhere safe. Not in your developer's password manager. In yours.
• Use a business email for the registrant contact, not a personal one. If you leave the business, the domain stays with the business.
• Register for multiple years if you can. It locks in the price and signals stability to search engines.

Hosting options explained

For the Gatsby sites I build, Netlify's free or Pro tier ($19/mo) is all most small businesses need. The site is static, so it loads fast, and the hosting cost is minimal. Shared hosting (Bluehost, SiteGround) makes sense for WordPress sites. VPS and dedicated hosting are overkill for a five-page local business site.

What I do differently

I do not hold anything hostage. Here is the short version:

• Your domain is in your account
• Your hosting is in your account
• Your content is yours, with source files delivered
• Your source code is in a repo you own or receive as an archive
• If you leave, I help you migrate. No fee, no friction.

The details are in my terms and service scope. If you have questions before hiring me, use the contact page and ask. I would rather answer these questions upfront than have you find out the hard way that your last developer locked you in.

Owning your website is not complicated. It just requires someone willing to set it up that way from the start.