The website that costs nothing to run

A small business site is not a hard computing problem. Twenty pages, some text, a few images, a contact form, maybe a list of products that changes once a month. The whole thing could be printed on paper and posted through a letterbox, and for most of the internet's life that is roughly how it was served: files on a disk, handed to whoever asked.

Somewhere along the way this became expensive. Not the design, not the writing, the running of it. A brochure site ends up on a stack that needs a build server, a database, a content system with monthly seats, a plugin for the form, a plugin for the sitemap, a plugin to make the other plugins faster, and a monthly bill that arrives whether or not anyone visited.

It does not have to be that way, and the gap between the two approaches is much wider than most owners realise.

What actually happens when a page loads

The browser asks for an address. Something answers with HTML. If that HTML is already written and sitting there, the answer takes a few milliseconds and the page starts painting immediately.

If the HTML has to be assembled first, the request wakes a server, the server asks a database for the content, a template turns that into HTML, and only then does the answer start moving. Every step is small. Together they are the difference between a page that appears and a page that arrives.

Caching layers exist to hide this, and they work, right up until the cache is cold, or the plugin that manages it conflicts with the plugin that minifies the CSS, and then the customer on a phone in a weak signal area waits four seconds for a page whose content has not changed since March.

The question worth asking about any small site is simple: why is this being built again for every visitor, when it was the same for the last thousand?

Build once, serve forever

The alternative is old and unfashionable. Write the content as plain files. Run a script that turns those files into finished HTML pages. Upload the pages. Serve them from machines placed close to the people asking, so the bytes have less distance to travel.

That is a static site on an edge network, and for the kind of business described above it is not a compromise. It is a better fit than the dynamic version in every dimension that matters: speed, hosting cost, security surface, and the number of things that can wake you up at night.

My own sites are built this way. Content lives in plain text and JSON. A short build script produces the HTML. A small worker sits in front and handles the few things that genuinely need to happen per request, such as security headers and the contact form. There is no framework, no database, no admin panel, and no library update that can break the layout on a Tuesday.

The hosting for most of them costs nothing, because the free tier of an edge platform is far larger than a small business site will ever consume. The real bill is the domain, and sometimes a few dollars a month for extras. What the client pays me for is the building and the maintenance, not for renting a server that spends its life idle.

What you give up

This is the part most articles about static sites skip, so here it is plainly.

Editing is not point and click. There is no dashboard where a staff member can drag a new section onto the homepage. Content changes go through files, which means they go through me, or through a small editing layer someone has to set up. For a business that changes its site twice a year this is irrelevant. For one that runs daily campaigns it is a real cost.

Anything genuinely dynamic needs separate thought. User accounts, live inventory, a real shopping cart with stock counts. These are all possible alongside a static site, but they are their own pieces of work and they are not free.

Someone has to run the build. If the site is built by a script, that script is now part of the business. It needs to be documented, it needs to run somewhere other than one laptop, and the person who inherits it needs to be able to run it without a phone call.

I mention these because the honest version of this argument is not that static sites are always right. It is that for a brochure site, a portfolio, a landing page, a local service business, a restaurant, a clinic, the dynamic version is paying a permanent tax for flexibility it uses twice a year.

The parts worth keeping strict

If you do build this way, a few decisions carry most of the benefit.

Keep the HTML honest. Headings in order, real links, real buttons, labels attached to inputs. This is what makes a page work with a screen reader, and it happens to be what makes it legible to search crawlers and to the language models that increasingly summarise a business before a human ever visits it. The same discipline serves all three audiences.

Keep fonts and images under control. One subset font file that only contains the characters the site uses, images sized for the space they occupy, dimensions written into the markup so nothing jumps as the page settles. Most of what feels slow on a phone is not the server, it is layout shifting under the reader's thumb while a font swaps.

Send almost no JavaScript. Not out of purity. Because every kilobyte of it has to be downloaded, parsed and executed on a five year old phone on a busy network, and almost none of it is doing anything the browser cannot already do natively in 2026.

Put security headers on every response and mean them. A strict content security policy is more work to live with, and it is the difference between a compromised script somewhere in your supply chain being an incident and being a non-event.

What this looks like to the person paying

They do not see any of the above, and they should not have to.

What they see is a site that opens before they have finished lifting their thumb, a hosting bill that does not scare them, a form that reaches a phone in seconds, and a year in which nothing broke because nothing needed updating.

That is the whole argument. Not that the stack is elegant, though it is. That the boring choice is cheaper to run, faster for the customer, and quieter to own, and those three things compound for as long as the site is alive.