A friend asked me last week why I don't use Bluehost, and I started answering and realized I was answering the wrong question. He wasn't asking about a company. He was asking what the pieces are, because nobody had ever laid them out for him, and there's no reason he'd know. The industry isn't built to lay them out.
Most people buy a website the way you'd buy a car. One thing, one price, one company. It's closer to renting an apartment, where the building and the address and the furniture and the utilities are four separate arrangements that happen to show up on one bill.
So here's what the pieces are, what each one does, and what I use for each.
The five layers
The domain. Your address. yourbusiness.com is a name you lease from a registrar, usually ten or twenty dollars a year, and it points at whatever you tell it to point at. It is the one piece almost everybody already owns outright, and it's the most important one, because it's the part your customers know.
The code. The actual instructions for what your site looks like and does. Every page, every button, every form. This is the thing people mean when they say "my website," and it's a folder of text files.
The host. The computer that runs that code when somebody types your address. Somebody lands on your domain, the host wakes up, runs the code, and hands the browser something to draw. No host, no site.
The database. Where the stuff that changes lives. Accounts, form submissions, orders, inventory, anything the site remembers between visits. Think of it as a spreadsheet the code can read from and write to very fast. A simple brochure site may not need one at all.
The services. Everything the site hands off to somebody else. Sending email, taking payments, tracking traffic, hosting video. Each one is a separate company with a separate account.
That's it. Five layers, and every website you have ever used is some arrangement of those five.
A bundled provider like Bluehost or Squarespace or Wix sells you all five as a single product with one login, and there is a real reason people choose that. It works, it's cheap, and you don't have to think about any of this. WordPress still runs about 41% of all websites on the internet, and a lot of those sites are doing their job fine. The tradeoff is that the layers come welded together. Changing one means changing all of them, which is why "we should move the site" always turns into a rebuild instead of a swap.
The layer nobody mentions
There's a sixth thing that isn't a layer, exactly, but it changed how I work more than any of the five.
On the old model, your code lives in one place, on the host, as one live copy. You edit a file and the old version is gone. If something breaks on a Tuesday afternoon you're reconstructing from memory, and if you had a person build it for you and that person moves on, you're reconstructing from their memory.
The modern arrangement splits that in two. The code lives in a repository, which is a version-controlled folder, and I use GitHub for it. Every change you make is saved as a snapshot with a date and a note about what changed. Nothing is ever overwritten. You can stand at any point in the site's history and look at exactly what it was that day, and go back to it.
The host then pulls from the repository rather than holding the only copy. So the code is yours, sitting in your account, and the host is a thing you point it at.
That's the upgrade. Not speed, not features. You get a history and an undo button for your entire business's front door.
What I use, and why
| Layer | What I use | Why |
|---|---|---|
| Domain | Whatever registrar the client already has | Not worth moving. It's the one piece that's already theirs. |
| Code | Next.js | It's the most common framework for building modern sites, it's fast, it's built for search engines to read, and the code is plain and portable. A different developer can pick it up. |
| Repository | GitHub | Full version history, one-click rollback, and the client's name on the account. This is the ownership piece. |
| Host | Vercel | Pulls straight from GitHub. Every change gets a preview link to review before it goes live, and going back to the previous version is one click. |
| Database | Supabase | Managed Postgres, which is the boring, forty-year-old database standard that everything speaks. Open source, and self-hostable if you ever want out. |
| Services | Whoever's best at the one thing | Email, payments, analytics. Separate accounts on purpose, so a bad one can be replaced on a Tuesday. |
Every layer is swappable without touching the others, and that's the point. The domain points wherever. The code runs on any host that speaks Next.js. Postgres data moves to any other Postgres. I like this arrangement because when a client and I stop working together, they leave with the whole thing, and nothing in the stack is holding their business hostage.
Worth being straight about the cost of that: it's more accounts, more logins, and more small bills instead of one. If you never want to look under the hood, a bundle is a defensible choice and I'm not going to pretend otherwise.
Two people worth listening to, who don't agree
I'd rather hand you a real disagreement than a consensus that isn't one. These two have been building at the top of this for two decades and they land in opposite places.
David Heinemeier Hansson, who most people call DHH, created Ruby on Rails and runs 37signals, the company behind Basecamp. He argues you should own your computers rather than rent them, and he did it out loud: 37signals left Amazon's cloud, AWS, starting in 2022, spent around $700,000 on their own servers, cut a $3.2M annual bill to under a million, and closed the Amazon account for good in October 2025. His sharpest version of the argument is that renting compute by the slice carries a structural markup, so if your workload needs a whole computer most of the time, you should own that computer. He's also pointed out the part nobody models: a batch of servers he bought in 2015 ran until 2025, which works out to about $142 a day to run the whole company.
Guillermo Rauch created Next.js and runs Vercel, and his position is that infrastructure should disappear. You should think about your product, not about servers, and the platform should absorb the rest. Vercel raised $300M in late 2025 at a $9.3B valuation on that thesis, and it now handles around six million deploys a day, more than half of them triggered by AI coding agents rather than people. On the lock-in criticism, his answer has been to ship a fix for it: in March 2026 Next.js shipped a public adapter contract so the framework runs properly on Cloudflare, Netlify, and AWS, with Vercel's own adapter using the same public path as everyone else's.
Where they differ: Hansson thinks the rental market has a permanent markup and the only real escape is ownership. Rauch thinks the capability you rent, previews and global distribution and now agents, is worth more than the markup and can't be rebuilt on your own hardware at any sane price.
I sit with Rauch on hosting and with Hansson on everything above it. For a small business, renting the computer is cheap and swapping hosts is a Tuesday. The ownership that matters is one layer up, in the code and the domain and the data, and that's the part the bundle quietly keeps.
Rent the machine. Own the thing running on it.
What I'd do first
If you have a site now and it's working, this is not an emergency. Sites earn their replacement, they don't age into it.
- Find out who owns your domain. Log into the registrar. If you can't, that's the first thing to fix, before anything else, because everything else points at it.
- Ask where your code lives and whether there's a history. If the answer is "on the host" and there's no version history, you're one bad afternoon from a rebuild. Worth knowing either way.
- Ask what happens if you leave. Whoever built it, whoever hosts it. What do you walk out with. If the answer is "an export," you were renting.
- Separate the pieces you can, cheaply. Move email off the host. Point analytics somewhere that isn't the builder. Small moves that cost nothing now and save the whole migration later.
- When you do rebuild, rebuild on layers. That's the whole argument, and it isn't about a vendor. Layers you can swap one at a time, whoever you swap them for.
How this connects to everything else
The reason I care about this in a marketing context, and not just as a preference: the stack is what makes the rest possible.
A site that's fast, crawlable, and structured is a site both Google's index and an AI assistant's retriever can work with, and that's mostly decided by the code layer before you write a single word. I wrote the two companion pieces on that: SEO: A Five-Minute Primer for how classic search works, and AEO: A Five-Minute Primer for the AI-answer version of the same question.
Pick the stack first. It's the one decision underneath all the others.
If you'd rather hand the whole thing to someone, that's what I do.
Figures cited: W3Techs CMS usage (September 2026), 37signals' published cloud-exit accounting, Vercel's Series F announcement and Ship 2026 figures, and the Next.js 16.2 release notes. Positions attributed to David Heinemeier Hansson (37signals) and Guillermo Rauch (Vercel) are my summary of their published work, not quotes.
