A post on my LinkedIn feed this week asked whether a business should build its website as a static site or on a CMS. The usual answers followed: static is faster and safer, a CMS lets you edit content yourself. Both are true, and neither answers the question that matters, which is who should be making the decision at all.
When the Owner Has to Decide
The static-or-CMS question reaches the business owner when they work at a low level of abstraction. In practice that means one of three things:
- They keep the reins on many parts of running the website. They renew the domain, edit the DNS, chase the contact form when it stops sending, and decide which plugin to install.
- They think about this year, not the next five. The cheapest way to get a site live this quarter wins.
- They have not owned a website for long. The question looks technical, so they assume it is theirs to answer.
At that level the choice really is theirs, because they will live with the plumbing. A static site means every text change goes through someone who can run the build. A CMS means updates, plugins and a login to protect. The owner has to weigh those because nobody else is carrying them.
Bundle the Plumbing and the Question Moves
Most of what makes running a website hard is the same job on every site:
- transactional email delivery, so contact forms and order confirmations arrive
- monitoring, so someone other than a customer notices the site is down
- virus scanning and cleanup
- DNS, which the email and the CDN both depend on
Once those are part of the service, the owner is buying a working website. How the pages are generated stops being their decision, in the same way that the database engine behind their accounting software is not their decision. They care that it works, that it is fast, and that they can change what they need to change.
The Agency’s Question Is Different
When the decision moves to a full-service agency, the question changes. It is no longer “static or CMS?” but “who owns the long-term value of the CMS choice?”
Many agencies run WordPress as if it were a custom CMS. Two patterns are common:
- The heavy theme. Content, layout and business rules are tied into a theme the agency maintains for years. It is WordPress on the login screen and a custom application everywhere else.
- Headless WordPress. WordPress holds the content and a separately built front end renders it, often with static-site techniques. The static-versus-CMS debate is already settled inside it: it is both.
Both approaches work, and both have good reasons behind them. Both also remove most of the customer’s practical option to walk to another agency. The next agency does not inherit a WordPress site. It inherits a custom application that happens to use WordPress, and it has to learn it before it can change anything. Sometimes that is the intention.
Lock-in Is a Price, Not a Crime
I do not think lock-in is wrong in itself. It is a price, and some customers are happy to pay it for what they get: a tailored editing experience, a fast front end, an agency that knows every corner of the build.
The problem is a customer who never knew it was on the invoice. WordPress is the largest labour market in the web industry, but only for sites built the way that labour market expects. A standard theme, a handful of well-known plugins and small custom code in a custom plugin can be picked up by thousands of developers. A bespoke theme or a headless front end narrows that to the people who built it. That is the same question as whether your platform has an exit, asked one layer up.
What to Ask Instead
If you are a business owner asking static or CMS, you are probably still running too much of the website yourself. Hand over the plumbing first, and the question will mostly answer itself.
If your agency is answering it for you, ask one more question before you sign: if we part ways, what does the next agency inherit? A good agency will have a straight answer. It may even be “a custom application, and here is why that is worth it to you.” That is fine, as long as you heard it before the build rather than after.
