How to choose a CMS you will not hate

Most people pick a CMS the wrong way round. They start with a list of platforms, read some comparison posts, and then try to work out which one fits.

Start at the other end. Work out who is going to edit the site, how often, and what they need to change. The right platform falls out of that answer.

The question that decides it

Who touches the site after launch?

There are really only three answers, and each one points somewhere different.

Nobody, or almost nobody. A five page site that changes twice a year. You do not need a CMS at all. You need a developer on call and a site that is cheap to edit.

One or two non technical people, weekly. A marketing person adding blog posts, updating prices, swapping a photo. This is most service businesses. You need something simple with guard rails.

A team, daily, across many page types. Multiple authors, review steps, maybe more than one language. This is where the serious systems earn their cost.

Buying for the third case when you are the second is the most expensive mistake in this whole area. You pay for a system nobody uses properly and everything takes longer than it should.

The three kinds, in plain terms

Ignore the marketing pages. There are three shapes.

Traditional

The CMS holds your content and also builds the pages. WordPress is the obvious one. Squarespace and Wix work the same way from the user's side.

Everything is in one place, which makes it simple. It also means the way your site looks is tied to the tool that stores your words. Changing one usually means redoing the other.

Headless

The CMS holds your content and nothing else. It hands the content over through an API, and a separate front end builds the pages. Sanity, Payload and Contentful work like this.

The site can be fast and built however you want. Your content is not locked to a design. The cost is that you need two things instead of one, and someone has to build the front end.

Site builders

Webflow, Framer and friends. You design in the tool and it publishes the site.

Very quick to get going. The limits show up later, usually when you need something the tool does not do, or when you want to move somewhere else.

Traditional or headless

This is the choice most businesses actually face. Here is the honest comparison.

	Traditional	Headless
Time to launch	Faster	Slower
Cost to start	Lower	Higher
Page speed	Depends on plugins	Usually very good
Editing experience	Familiar to most people	Cleaner, but new
Redesign later	Rebuild the whole thing	Change the front end only
Plugins available	Thousands	Few. You build instead
Security work	Ongoing and real	Much smaller surface
Locked in	Somewhat	Less so

Traditional wins on speed to launch and on cost. Headless wins over three to five years, especially if you expect to redesign or add a second place your content needs to appear.

Neither is the correct answer in general. They are the correct answer for different situations.

Questions to ask before you commit

Write your answers down. Show them to whoever is building the site.

How many people will edit it, and how technical are they? Be honest. The answer is usually fewer and less technical than the plan assumes.

What breaks if the site is down for a day? If the answer is nothing much, you can accept simpler hosting. If it is a real revenue problem, that changes the budget.

Will this content need to go anywhere else? An app, a partner site, a newsletter, in store screens. If yes, headless saves you real pain later. If no, it is solving a problem you do not have.

How often will the design change? A brand that reworks its look every two years should keep content and design separate. One that will not touch it for five years does not need to.

Who fixes it at 9pm? Every platform breaks eventually. Knowing who picks up the phone matters more than any feature list.

About WordPress

WordPress runs a huge share of the web, so it deserves a straight answer rather than a fashionable one.

It is a good choice when you need many contributors, want a large pool of people who already know the tool, and need a specific plugin that exists and works.

It is a poor choice when speed matters a lot, when your plugin list is already long, or when nobody is going to keep it updated. An unmaintained WordPress site is a security problem waiting to happen, and the cost of that shows up all at once.

The version of WordPress people complain about is usually one with 30 plugins and no maintenance. That is a process problem as much as a platform problem.

What "your team can edit it" should mean

Every platform claims this. Very few deliver it. Here is what to actually check in a demo.

Can they preview before publishing? If the only way to see a change is to publish it, someone will publish a half finished page on a Friday.

Are there guard rails? A good setup makes it hard to break the design. If an editor can drag a heading into the footer, eventually one will.

Is the content in real fields? A single box of rich text is a warning sign. Title, summary, image and date should each have their own field. That is what lets the same content appear correctly in a list, on a card and in a search result.

Can two people work at once? Small teams hit this sooner than they expect.

Does it work on a phone? Somebody will need to fix a typo from a train.

Sit the person who will actually use it in front of a demo and ask them to add a page. Watch without helping. You will learn more in ten minutes than from any feature comparison.

The cost you will pay every year

The build is one number. Running it is another, and it is the one people forget.

	Traditional	Headless	Site builder
Licence or plan	Often free	Free tier, then per seat	Monthly, per site
Hosting	Cheap to moderate	Cheap	Included
Updates and security	Monthly work	Handled for you	Handled for you
Developer time	Regular	Occasional	Rare
Cost of adding a page type	Low	Medium	Low, within limits

The row that surprises people is updates. On a traditional platform with plugins, someone needs to apply updates, check nothing broke, and keep backups. That is a few hours a month, every month. Either you pay for it or you skip it and carry the risk.

What migration actually costs

People underestimate this every time. It is rarely the CMS that takes the effort.

The real work:

Cleaning the content. Old sites carry pages nobody has read in years. Decide what moves and what dies. This is a day of decisions that only you can make.

Keeping your search rankings. Every URL that changes needs a redirect to the right new page. Miss this and traffic you spent years earning disappears in a week. When we moved Jay Yang to a new build and a new domain, mapping redirects was a bigger job than building several of the pages.

Redoing the structure. Content in an old CMS is often a big lump of formatted text. To use it properly in a new one it needs real fields. Title, summary, author, image, each in its own place.

Retraining people. Two hours of showing your team the new tool saves months of them not using it.

A migration where the content is tidy might take a week. One where it is fifteen years of unsorted pages can take a month. The platform choice barely moves that number.

Matching platform to situation

A rough guide. Find the row that sounds most like you.

You are	Reasonable choice	Why
A solo consultant, 6 pages	Site builder or simple traditional	Cost and speed matter most
A firm with a blog and one editor	Traditional, kept lean	Familiar, cheap, enough
A growing company, speed matters	Headless	Fast pages, room to change
A team of five publishing daily	Headless with workflow	Review steps and roles
Content needed in an app too	Headless	Only real option
Heavy regulation, data cannot travel	Self hosted, either kind	Control beats convenience

None of these are rules. They are starting points that stop you buying a platform three sizes too big.

A short checklist

Before you sign anything:

• Can the people who will use it actually use it? Sit them in front of a demo
• Can you export everything, easily, without a developer?
• What does it cost at ten times your current content volume?
• Who is responsible for updates and security?
• If you leave in three years, what comes with you?

That last one is the question nobody asks and everybody regrets.

What we do

For most of our clients we build on Next.js with a headless CMS behind it. The site is fast because the pages are built ahead of time, and the client can edit without touching code or waiting on us. The speed side of that choice is covered in what a slow website is costing you.

That is not the right answer for everyone. If you have a small team, a small budget and a simple site, a well maintained traditional setup will serve you fine. What matters is that the choice is made on purpose.