Static websites. Nothing to update, nothing to break in.

What "static" actually means

On a typical WordPress site, every single visit sets off a chain of work: PHP starts up, the site queries a database, plugins run, and a page gets assembled from scratch — then thrown away and assembled again for the next visitor. All of that happens while someone waits.

A static site does that work once, on my machine, before the site ever goes live. The result is plain HTML files sitting on a server. When someone visits, they're handed a finished page. There's nothing to compute, nothing to query, and nothing to go wrong under load.

This isn't a compromise or a stripped-down option. It's how the fastest sites on the web are built, and for a brochure site, a practice, a restaurant, or a small business, it is almost always the correct answer.

The part nobody mentions when they sell you WordPress

WordPress is not bad software, and I'm not going to pretend otherwise — it runs a large share of the web for good reasons. But it's usually sold as a one-time build, and it isn't one. It's an ongoing obligation, and the bill arrives later.

A typical site runs a dozen or more plugins written by a dozen different authors of varying diligence. Each one is a way in. Each needs updating. Updates occasionally break the site, which means someone has to be watching — and the overwhelming majority of hacked small business sites I've been called about were compromised through an out-of-date plugin, not through anything clever.

A static site has none of that surface. No database to inject, no admin login to brute force, no plugin ecosystem to maintain. The attack surface isn't reduced — it mostly isn't there.

Built with CampsiteJS — which I wrote

I build these with CampsiteJS, a static site generator I wrote and maintain myself, paired with TailwindCSS for the interface. This site is built with it.

The practical difference is response time. When something needs to change in how the site is generated, I'm not filing an issue against someone else's project and waiting — I open the source and fix it. Over a multi-year relationship that turns a category of "we can't do that" into an afternoon.

The fair question is whether that locks you in. It doesn't, and I want to be specific about why rather than just asserting it:

• What you're given is plain HTML, CSS, and images. Any developer alive can host, read, and edit those. There's no runtime and no proprietary format in what gets served.
• It's a build tool, not a platform. CampsiteJS runs on my machine to produce the site. It isn't a service you'd depend on, and nothing about your live site needs it to keep working.
• The source is standard. Templates are Nunjucks and styles are Tailwind — both widely used, both documented publicly, neither invented here.

If you leave, you leave with a working website. That's the test I'd apply to anyone else and it's the one I hold myself to.

"But I need to edit it myself"

This is the reasonable objection, and it deserves a straight answer rather than a dodge.

Static doesn't mean frozen. Content that changes regularly — staff, services, hours, posts, locations — lives in structured data files rather than being buried in the markup, and those can be edited without touching code. Where it's genuinely warranted I can wire up a proper editing interface that commits changes and rebuilds the site automatically.

But I'd also gently push back on the premise. Most small business owners who insisted on full editing control logged in twice in the first month and never again — while carrying the cost and risk of a whole content management system to support it. If what you actually need is a phone number changed twice a year, that's a five-minute email, not a platform.

When a static site is the wrong answer

I'd rather say this plainly than sell you the wrong thing. A static site is a poor fit the moment your site needs to remember who someone is and act on it — customer accounts, private dashboards, real payment processing, inventory that has to stay accurate, bookings that hold a slot against everyone else.

That's an application, and it's a different build — see Laravel development. Plenty of projects are also a hybrid: a fast static site for everything public, with one application-shaped piece doing the real work. That's frequently the cheapest thing to build and the easiest thing to live with.