Who Actually Owns Your Website? A Plain-Language Guide to the Keys

A website is not one thing

When people say "our website," they usually mean the pages they can see. But a website is really a small stack of services, each with its own account, its own login and its own bill. Who owns each of those accounts decides who's actually in charge.

Front end and back end, in plain English

The front end is everything a visitor sees and touches: pages, text, images, buttons and forms. The back end is everything behind the curtain: where the content is stored, the database, the servers that send the pages, and the logic that runs when someone submits a form or logs in.

Think of a restaurant. The front end is the dining room. The back end is the kitchen, the pantry and the supplier contracts. You can own a lovely dining room and still not have a key to the kitchen.

The keys, one by one

The domain name. Your yourbusiness.com. You rent it year by year from a domain registrar. Whoever's name is on the registrar account controls the domain, and with it your web address and usually your email. This is the most important key on the ring.

DNS. The internet's address book, telling browsers and mail servers where your website and email actually live. It's often managed at the registrar, but not always. Change a DNS record and your site or your email can move, or vanish.

Hosting. The servers that store your site and send it to visitors. Sometimes bundled with the platform, sometimes a separate account with a separate bill.

The CMS. The content management system, where your team logs in to edit pages and posts.

Everything around it. Google Analytics, Google Search Console, your Google Business Profile, ad accounts, form tools, newsletter platforms, payment processors. Each one is an account, and each account belongs to someone.

Under the hood When someone types your address, their browser asks DNS where to go. Your registrar points the domain at a set of nameservers, and the records on those nameservers point to your web host (A or CNAME records), your email provider (MX records), and the verification codes services like Google use to confirm you control the domain (TXT records). Whoever can edit those records can redirect your site or your email, which is why that login matters as much as the website itself.

How the usual setups compare

WordPress on shared hosting. WordPress itself is open source, so in theory you own everything. In practice, the hosting account, the premium theme license and a pile of plugin licenses are often under the developer's name, and the person who knows how it all fits together is the one who built it. If they move on, you inherit a puzzle.

Wix or Squarespace. Simple and all in one: domain, hosting and editor under one login, usually yours. The catch is that the site only exists on that platform. You own the account and your content, but you can't pick the site up and move it somewhere else. Leaving means rebuilding.

A custom agency build. Often the most powerful and the most tangled. The code might live in the agency's repository, on the agency's servers, under the agency's cloud account, and the contract decides who owns what. Plenty of businesses discover the answer the day they try to leave.

How we set it up

We start from one rule: the keys are yours. Here's the stack we build on, and who holds each piece.

• The front end: Webflow. Your marketing site, designed in Webflow with a CMS your team runs. It lives in a Webflow account in your name, or we move it there whenever you ask, at no charge.
• The apps: Next.js and React on Vercel, with Supabase. When your business needs software, like a member portal or a team dashboard, we build it beside your site, usually at app.yourdomain.com. The code, the hosting and the database sit in accounts under your organization.
• The connectors: Cloudflare Workers. Small services that move data between your site, your app and the tools you already use, like an event platform or a newsletter. They run in a Cloudflare account that's yours too.
• Your domain, DNS and every account around the site stay in your organization's name. We get the access the work needs, and nothing more.

Under the hood Next.js is a React framework for building web apps, and Vercel deploys it worldwide straight from your code repository. Supabase is a managed Postgres database with sign-in and row-level security built in, so each person can only read the rows their role allows. Cloudflare Workers are small functions that run on Cloudflare's network and react to events, like a webhook from your ticketing platform, with no server to babysit. Each piece lives in its own account, and each account belongs to you.

Here's what that looks like in real life: every integration we built for Blackwood Land Institute, from the Eventbrite sync to the newsletter signup, runs on infrastructure Blackwood owns. (Read the case study.)

Why we do it this way

Because we'd rather earn the next month than lock you in. If you ever want to walk away, the keys go with you. It's how the accounts are set up on day one, not a promise we make at the end.

Your five-minute ownership audit

• Log in to your domain registrar. Is the account in your name, with your email?
• Check when the domain renews, and make sure auto-renew is on.
• Find out where your DNS is managed, and whether you can log in there.
• Confirm you're an owner or admin in Google Analytics, Search Console and your Google Business Profile, not just a viewer.
• Ask whoever built your site where the code and content live, and whose account that is.

Any answer you're not sure about is worth a conversation. If someone else holds your keys, a move is a great time to fix it (here's what a migration involves), and so is a custom app built in your own accounts. And yes, this is also why we're skeptical of asking AI for a website and calling it done.

Want a second pair of eyes on your keys? Book a free consult. We'll walk through it with you, no strings attached.