When someone visits a website, the page they see has to come from somewhere. There are two broad ways to make that happen, and the difference between them quietly decides how fast, how reliable, and how secure a site turns out to be.
The first way is to build the page fresh on every single visit. Someone asks for your home page, and a program on the server springs into action - queries a database, fetches your content, stitches it into a template, and hands over the result. That’s how a typical WordPress site works, and it’s how most “platforms” work under the hood.
The second way is to build every page once, ahead of time, and save the finished files. Then when someone visits, the server just hands over the page that’s already sitting there, ready. That’s a static site, and it’s what we build.
The bakery, not the kitchen
A restaurant kitchen cooks each meal to order. That’s powerful when every order is genuinely different, but it means staff, equipment, and a bit of a wait for every plate. A bakery makes the loaves in the morning and lines them up on the shelf. You walk in, point, and leave with bread. No waiting on anyone to assemble it.
Most business websites are bakeries pretending to be kitchens. The pages are the same for everyone who visits - your services page doesn’t need to be freshly cooked per person - yet the site does all the work of a kitchen anyway, every time, for no benefit.
Why this is the right default
Serving a finished file is about as fast as the web gets, because there’s no program running and no database to wait on - the page is already there. We dug into the broader picture in what actually makes a website fast, and “build it ahead of time” is a big part of the answer.
It’s also far sturdier. There’s no database to corrupt, no login screen to brute-force, no pile of plugins each adding its own way to be hacked. A huge share of website break-ins target exactly that machinery, and a static site simply doesn’t have it - a point we touched on in the hidden cost of page builders. Less machinery means less to go wrong and less to defend.
And it’s cheap and tough to host. Plain files can be copied to servers around the world and served from whichever is nearest the visitor, so the site stays quick everywhere and shrugs off a traffic spike that would topple a database-driven setup.
“But I need to update it”
The usual worry is that “static” means “frozen.” It doesn’t. Static describes how the page is served, not whether you can change it. When you edit your content, the site is rebuilt - the pages are baked fresh with your changes and the new files go live. You edit in a friendly place; a build step turns that into fast static pages. (This very site publishes new journal posts that way, on a schedule.) You get the convenience of editing and the visitor gets the speed of a finished file.
When you’d want the kitchen
Static isn’t the answer to everything, and we’ll tell you when it isn’t the fit. If your site has to show genuinely different content per person, handle logins and accounts, run a large live-inventory store, or react to data in real time, you need a server doing work on each request. That’s a real category of project. It’s just not most marketing sites, and building one as though it were a live application means paying for a kitchen to run a bakery.
For the websites most businesses actually need - to explain what they do and bring in work - a static site is faster, harder to break, and cheaper to keep running. That’s why it’s our default, and why we reach for anything heavier only when there’s a concrete reason to. If you’re curious whether yours is a bakery or a kitchen, tell us what it needs to do and we’ll give you a straight read.
