Why we still build static sites in 2026.

Every year someone declares the static site dead. Every year, on the small projects we actually build, the static site quietly wins. It loads faster than the alternatives, costs less to host, breaks less often, and — my favourite property — keeps working three years later when nobody has logged in.

This isn't a contrarian take. It's just maths.

What "static" actually means

A static site is a folder full of files (HTML, CSS, images, maybe a little JavaScript) that a server hands out as-is, without running any code per request. We push the folder to S3, point CloudFront at it, and the same flat file is served to every visitor — usually from a city closer to them than our office.

What this does not mean:

• It doesn't mean the site can't have a CMS. We build the HTML from a CMS at publish time, not at request time.
• It doesn't mean no forms, no checkout, no analytics. Those run as small serverless endpoints called from the page.
• It doesn't mean ugly. The fastest sites we make are also the most beautifully typeset.

The part where we save you money

A typical small-business site we host on AWS — pages, form, analytics, a small shop — costs under €5 a month, including media. Compare that to a managed WordPress plan starting at €25–€40, and the difference compounds: less to spend, less to renew, less to hand off when the volunteer with the password leaves.

The boring part is also the part you pay for ten years.

The part where we save your visitors' phones

A modern WordPress homepage with a builder plugin and a fashionable theme often weighs 3–6 megabytes by the time the front page is interactive — most of it JavaScript. On a 3G phone in rural Clare, that's a six-second wait staring at a blank screen.

The static homepage we ship for the same client weighs about 120 KB. It paints in well under a second. Nobody has to wait.

This matters more than it sounds. The folks visiting a small charity's website aren't usually sitting at a fibre desk in Dublin 2 — they're a parent on a phone, on a bus, with two bars of signal. If the site doesn't open in two seconds, they don't read it. The cause loses out, not the technology.

Where static stops being the answer

We're not zealots. Static is the wrong tool when the page genuinely needs to be different per visitor — a logged-in dashboard, a real-time bookings calendar, a map showing who's nearby. For those bits we use a sprinkle of dynamic — a Lambda, a cmsworkbench API call, a small bit of front-end state — without throwing the whole house away.

The general rule: static by default, dynamic by exception. The exception should have a reason somebody can explain in one sentence.

What we're getting wrong

Honestly? Editing copy is still slightly more work for our clients than it should be. The CMS handles the words, but a "publish" button still triggers a deploy. We're shaving that down. The next round of cmsworkbench will let editors push a change and see it live within seconds — no developer, no waiting.

If you've read this far and you've got a small site that's slow, expensive, or fragile — drop us a line. We probably have a static answer for it.