Does your site actually need a CMS?

WordPress is one of my main tools. I have built booking systems, multilingual catalogues and custom admin interfaces on it, and for most business sites it is the right answer.

This article is about the cases where it is not, and why I sometimes talk clients out of the thing I am best at selling.

What a CMS actually costs

The licence is free. The cost is somewhere else, and it is recurring.

A content management system means a database, which means backups that include a database and a restore procedure that is more complicated than copying files. It means a login page, which is the single most attacked URL on the internet. It means an update cycle — core, plugins, PHP versions — where each update is small and the obligation is permanent. It means a plugin surface, and every plugin is a supplier whose security record you have inherited. It means server requirements: PHP, a database, more memory, and hosting priced accordingly.

None of that is an argument against a CMS. It is the price of a real benefit: your team edits content without a developer. The question is whether you are getting that benefit.

The arithmetic

The honest test is a division. How often does the content change, and how much does each change cost through each route?

I built a detailing shop site where the answer was stark. The content changes maybe four times a year: two price adjustments and a couple of new documented jobs. Nothing else on that site has any reason to change.

Four edits a year against a database, a login, an update cycle and a plugin surface, paid every month, forever. The maths does not work. It is not close.

So the site is hand-written HTML, CSS and JavaScript. No CMS, no page builder, no framework. Twenty-one stylesheets, one per section, loaded in the order the sections appear, so the first screen is styled by a handful of rules rather than by a megabyte of everything-on-every-page.

It has no login page, so it cannot be brute-forced. It has no database, so it cannot be injected. It has no plugins, so it cannot inherit somebody else’s vulnerability. Its backup is a folder. Its hosting is static file serving, which is the cheapest and most reliable thing a server does.

When the answer flips

I want to be equally clear about the other direction, because “static is faster” is as lazy as “everything needs WordPress”.

A CMS earns its cost the moment any of these is true:

• Content changes weekly or more. News, offers, stock, events. Anything with a rhythm.
• More than one person edits. The moment you need roles and permissions, you need a system.
• Content is structured and repeated. A hundred and thirteen courses, a hundred and forty-two locations, a hundred and fifty-one vehicles — these are records, not pages. Records belong in a database, and hand-maintaining them is not a plan.
• The content is the product. If publishing is the business, you need publishing tools.
• Non-technical people must be self-sufficient. If every change requires a developer, the developer becomes a bottleneck and the site stops being updated at all.

That last one is the real reason most business sites should use a CMS. Not editing convenience — independence. A site that requires me for every comma is a site that will be three years out of date, because the owner will stop asking.

Build so the decision can be reversed

Here is what makes the static choice defensible rather than reckless: it must not be a one-way door.

If the markup is structured — content separated from layout, sections that are genuinely repeating patterns rather than hand-placed one-offs, a clear boundary between the shell and the content — then moving it into a CMS later is a template job. A week, not a rebuild.

The detailing site was built that way deliberately. The documented-jobs section is a list, not a hand-placed collage, so it can hold fifty entries without a redesign. If the owner starts publishing a job a week, the arithmetic flips, and the migration is straightforward because the structure was already there.

The failure mode to avoid is the static site where every page is a bespoke arrangement of one-off markup. That one genuinely is a rebuild, and it is why “static” has a reputation for being a trap.

The middle ground people forget

It is not a binary. Between “hand-written files” and “full WordPress” there are options that suit a lot of small businesses better than either.

A static site with a small hosted form service and no other moving parts. A static site generator, where content lives in plain text files under version control and the output is static — you get editing without a database or a login. Or WordPress used strictly as an editing tool with a static export, so the admin exists but the public site is files.

Each of these is a different point on the same trade: how much independence do you need, and how much operational surface are you willing to run to get it.

Why I say this out loud to clients

Recommending less than you could sell is not altruism. It is the only way the recommendation means anything.

If I only ever propose the thing I am most practised at, my advice is worth exactly nothing, and a client who is paying attention will work that out. The value of hiring somebody who knows several answers is that they will tell you which one your situation needs — including when the answer is a cheaper one, and occasionally when the answer is that you do not need them at all.

For most business sites, that answer is still a CMS. For a shop that changes its prices twice a year, it is a folder of files, and pretending otherwise would cost the owner money every month for the rest of the site’s life.