Why your website probably doesn't need a CMS

Most of the websites I audit run on WordPress. Twenty pages, a blog updated three times a year, a contact form. And behind all that: a database, a PHP interpreter, a dozen plugins, a page builder, and a caching system meant to compensate for how slow the rest of it is.

That architecture was designed for a news site publishing forty articles a day. Applied to a small business website, it mostly produces side effects.

What over-engineering costs

A dynamic site rebuilds every page on every visit. The server queries the database, runs the code, assembles the result, then caches it to avoid doing it all again. When everything works, you notice nothing. When it doesn’t — a traffic spike, a slow plugin, an aggressive crawler — the server saturates and the page stops loading.

The attack surface follows the same logic. Every plugin is code executed on every request, maintained by a third party you know nothing about. One vulnerability in one of them is enough. On the sites I take over, the breach almost always comes from a forgotten plugin, not from the core application.

Then there’s maintenance debt. A PHP version reaching end of life forces a theme update, which forces plugin updates, some of which are no longer maintained. I have seen that chain paralyse sites for months, until the update became a project in its own right.

The alternative: build once, serve a thousand times

A static site inverts the logic. Pages are assembled once, at publication time. The visitor receives a ready-made HTML file, served from the point of presence closest to them.

No database queried on the fly. No code executed when the request arrives. No plugins to maintain. The page already exists — all that’s left is to hand it over.

The consequences are direct:

• Speed — response time no longer depends on server load but on network distance. From the Caribbean, that difference is measurable.
• Resilience — a traffic spike no longer takes the site down. Serving a static file ten thousand times costs almost nothing.
• Attack surface — no admin interface exposed, no database to inject, no plugin to exploit.
• Hosting cost — often divided by five or ten, sometimes down to nothing depending on volume.

When this approach doesn’t fit

It isn’t universal, and I don’t recommend it systematically.

A site publishing several times a day, with an editorial team working in parallel, genuinely benefits from a full authoring interface. A catalogue of ten thousand references with real-time stock levels has no business being static. Neither does a customer portal with authentication and personalised data.

The question isn’t “static or dynamic” in the abstract. It’s: what changes, how often, and for whom?

For a website updated a few times a month, the answer is almost always the same. The CMS solves a problem you don’t have, and bills you for that service in performance, security and maintenance time.

What about editing content?

That’s the systematic objection, and it’s a fair one. Nobody wants to open a code editor to fix a typo.

Two answers exist today. A lightweight editing interface can sit on top of a static site: the writer works in a familiar form, and publishing triggers an automatic rebuild. Or, when a single person manages the content, editing Markdown directly is more than enough — and often turns out to be faster than a page builder.

Either way, the constraint is smaller than people imagine. What usually blocks the move isn’t the tool: it’s the habit.

How to decide

Three questions are enough to frame the decision.

How often does the content really change? Not the frequency you hoped for at launch — the frequency observed over the past twelve months.

How many people publish? One person and a team of six don’t call for the same answer.

What are you paying today for maintenance? Hosting, updates, incidents, time spent. That figure is often the real surprise of the audit.

If your answers are “rarely”, “one” and “more than I thought”, the question deserves a serious look.