A CMS is the admin system that lets you change text and images without touching code. Which one to use is among the earliest decisions in a project and among the hardest to change later, so it is worth settling deliberately.
An unintuitive conclusion first: the deciding variable is people, not technology. Who updates the content, how often, and how much they are willing to learn. Technical merits come second to those.
WordPress
Around 40% of the web runs on it, the ecosystem is enormous, and a plugin exists for nearly anything.
Suits: frequent updates, several people editing, particular features like memberships, shops or bookings — and the situation where somebody else may take over later. People who know WordPress are everywhere, and that is worth more than it usually gets credited for.
The real cost: it is a dynamic system that assembles every page on request, so it is inherently slower than static and needs caching added. Plugins accumulate, conflict and slow things further. Above all it needs ongoing maintenance — security updates to the core and plugins have to be kept up, and an unmaintained WordPress is the most common thing on the internet to be compromised.
The right way to use it is as a content tool rather than as the thing serving your visitors. Our own site works this way: WordPress edits the content, visitors receive pre-generated static files, and the two are separate.
Site builders — Wix, Squarespace, Shopify
Drag-and-drop editing with no server, no updates and no backups to think about, and templates that work immediately.
Suits: limited budget, standard requirements, no technical support, wanting to be live quickly. A perfectly legitimate choice that does not deserve the snobbery it attracts.
The real cost: two things.
First, you cannot take it with you. Sites on these platforms generally cannot be exported intact, so moving means rebuilding. Ask before committing: if I leave, what do I get? Some platforms hand over a list of content and nothing of the structure or design.
Second, the platform sets your optimisation ceiling. Load speed, structured data, caching strategy — you can adjust whatever switches they expose and no further. Past a certain point the only way to get faster is to leave.
The monthly fee looks modest; total it over five years and include the cost of eventually migrating.
Static site generators — Astro, Hugo and similar
Content is written as files, assembled into complete HTML at build time, and deployed as plain files.
Suits: infrequent updates, high requirements for speed and security, and someone able to run a publish step. Most company websites fit — changed a few times a year, then published.
The advantages are real: no running software means no software vulnerabilities, the speed ceiling is very high, and hosting costs approach nothing.
The real cost: editing is awkward for non-technical people. A visual editor can be added, but that is another layer to maintain. If your content changes weekly, the friction becomes a genuine burden, and the usual outcome is that nobody updates anything and the site sits still.
Headless CMS
Content lives in a dedicated backend; the front end is built separately and fetches from it. Content and presentation fully separated.
Suits: the same content feeding a website, an app and other channels at once, or genuinely complex content structures needing strict schemas.
The real cost: for a small business website this is plainly over-engineered. You maintain two systems instead of one, at roughly double the cost, for flexibility you will mostly not use.
If someone proposes headless for a straightforward company site, it is fair to ask why.
How to decide
In this order:
1. How often does content change?
Weekly or more → WordPress or a builder; editing experience is not optional.
A few times a year → static, and accept occasional publishing friction for the speed and security.
2. Who makes the changes?
You, unwilling to learn anything new → a builder.
A staff member willing to learn a little → WordPress.
A technical person or agency maintaining it → any of them work.
3. Are there genuinely dynamic features?
Logins, payments, an admin interface → a dynamic system: WordPress or custom.
Presentation plus a form → a form can go to a service; it is not a reason to choose a dynamic system.
4. In five years, can you leave with it?
Ask this whatever you choose, and ask before signing. A good answer is specific: where the code lives, what format the data is in, how images come out, whether an export exists. A vague answer is itself the answer.
One combination that goes wrong constantly
WordPress with nobody maintaining it.
This is the most common bad situation we encounter: a WordPress site built some years ago and left alone since. Plugins three years out of date, core never upgraded, and eventually either a scanner finds a vulnerability or an abandoned plugin starts throwing errors.
WordPress is not the problem. The problem is that it requires attention, and “maintenance” is frequently absent from the quote — which makes the price look better without making the work disappear. It just goes undone.
So when comparing quotes, look past what gets built to who looks after it afterwards, what that covers, and how often. Whether that line exists matters more than which CMS is named.
We choose per project against the four questions above rather than pushing one answer. Hosting and maintenance are included for the first year and renewed annually, and that appears on the quote rather than being left blank.