Why we build small business websites as static sites

Most small business websites do the same handful of things: explain what the business does, list its services, show some proof, and give people a way to get in touch. None of that changes between one visitor and the next.

That observation decides the architecture. If every visitor sees the same page, there is no reason to build that page fresh on every request.

What “static” actually means here

A static site is compiled ahead of time. The build runs once, turns your content into finished HTML, CSS and images, and uploads the result to a CDN. When someone visits, the CDN hands back a file that already exists.

The alternative, a traditional CMS like WordPress, assembles each page on demand: a PHP process starts, queries a database, renders a template, and returns the result. That work happens again for every visitor, and it needs a server sitting there permanently, waiting.

Why it suits a small business

It is fast by default. The slowest part of loading a page is usually waiting for the server to think. Remove that step and the page starts arriving immediately, from whichever CDN edge is closest to the visitor. You get this without doing any performance work.

There is almost nothing to attack. No database, no plugins, no admin login on the public site, no server process running unpatched software. The most common way small business sites get compromised is an out-of-date plugin on an always-on CMS. A static site does not have that surface.

It costs very little to run. You are paying to store some files and serve them. There is no server billing you by the hour to sit idle overnight.

It does not rot. A site with no runtime has no runtime to fall out of date. The build tooling ages, but the deployed site keeps working exactly as it did the day it shipped.

What you give up

This is a real trade-off, not a free win.

Anything that has to differ per visitor at the moment of the request cannot be part of a static build. Customer dashboards, live stock levels, personalised pricing, anything behind a login. Those genuinely need a server rendering per request.

Rebuilds also take time. Publishing a change is not instant; it triggers a build and a deploy, usually a minute or two. For a site that publishes a few times a month that is irrelevant. For a newsroom it would not be.

The parts that still need a server

In practice a small business site usually needs one or two dynamic things, and those do not require making the whole site dynamic.

A contact form is the common one. The page stays static, and the form posts to a serverless function that only runs when someone actually submits it. You pay per submission rather than per hour, and the rest of the site is unaffected.

The same applies to search, booking widgets, or anything else that needs to run code. Isolate it, and leave the other ninety-nine percent of the site as files.

Where this leaves content editing

The objection people raise is that static means developer-only. It does not.

Content lives in files in the same repository as the site. A browser-based CMS edits those files, and saving commits the change and triggers a rebuild. The person writing a post sees a normal editor; the site gets the benefits of having its content versioned alongside its code.

That is the setup we use, and it is why publishing a post is a normal thing for a client to do rather than a support ticket.