CMS: how to tell a good one from a costly one

A content management system is the software that lets people update a website without writing code. That’s the whole promise, and it’s a genuinely important one. Before CMSs existed, changing a sentence on a web page meant editing a file and knowing what you were doing. A CMS puts a login screen and an editor in front of that, so a marketer can publish a blog post, swap a headline, or add a page without going anywhere near a developer.

The plain version: a CMS separates the people who write and edit content from the code that displays it, so the writing doesn’t require the coding.

That sounds simple, and the simplicity hides a lot of consequential differences between one CMS and another. Two systems that both “let you manage content” can lead to wildly different outcomes in cost, speed, and frustration over a few years. So this is both an explanation of what a CMS is and a guide to telling a good fit from an expensive mistake.

What a CMS actually does

Underneath the editor, a CMS is doing four jobs, and understanding them makes every later decision clearer.

It stores your content. Every page, post, image, and product description lives in the system, usually in a database, kept separate from the design that displays it. This separation is the core idea, and everything else follows from it.

It gives non-technical people a way to edit. The editor, the login, the publish button. Someone who has never seen code can write a page and put it live. This is the entire reason CMSs exist, and how well a system does this specific thing matters more than most feature lists suggest.

It manages who can do what. Editors can publish, contributors can draft, some people can only touch certain sections. On a team of any size this matters, because you don’t want everyone able to change everything.

It displays the content to visitors. The CMS takes your stored content, combines it with your design and templates, and produces the pages people actually see. How it does this is exactly where the different types of CMS diverge, which is the next section.

The two halves

The single most useful idea for understanding any CMS is that it deals with two separate things, and how tightly it binds them defines what kind of system it is.

There’s the content: the words, images, and structured information. Your article text, the product name, the price. This is what your team creates and edits, and ideally it’s stored in a clean, presentation-free way, so the same product description could appear on a web page, in an app, or on a partner’s site.

There’s the presentation: the design, layout, and templates that turn stored content into a page a human sees. Fonts, colours, spacing, where things sit.

A traditional CMS binds these tightly. The content and the templates that display it live together, and the system produces finished web pages directly. This is simple and convenient, and it assumes your content is going onto a website, which for most sites is exactly right.

A headless CMS separates them completely, storing only the content and serving it through an API, leaving presentation entirely to whatever front end you build. We’ve written about that separately; the thing to hold here is that “traditional versus headless” is really a question of how tightly your content and presentation are bound, and that binding is a genuine tradeoff rather than a matter of one being modern and the other old.

The main types

CMSs come in a few broad shapes, and matching the shape to your situation saves years of friction.

The traditional all-in-one CMS gives you content management and presentation in one package, producing websites directly. It’s the most common kind, it’s approachable for non-technical teams, and for a straightforward website run by marketers it’s usually the right answer. The tradeoff is less flexibility when your needs get unusual.

The headless CMS stores and serves content through an API and leaves presentation to you. It suits teams publishing to multiple places, or wanting complete control of the front end, and it assumes you have developers. Powerful and more demanding, and wrong for a small team that just wants to run a website.

The hybrid or decoupled CMS tries to sit between the two, offering the API flexibility of headless while keeping some built-in presentation help. It aims at teams who want headless benefits without giving up all the convenience. Whether it succeeds depends heavily on the specific product.

There’s also the split between self-hosted and SaaS, which cuts across the types. Self-hosted means you run the software on your own infrastructure, with full control and full responsibility, including updates and security. SaaS means the vendor runs it and you use it, trading some control for far less maintenance. For most teams today SaaS is the sensible default, and self-hosting makes sense mainly when you have specific control or compliance needs and the people to handle it.

Good fit from bad

Here’s the part the feature comparisons miss. Two CMSs can have near-identical feature lists and produce completely different experiences. A few things separate a good fit from an expensive one, and none of them show up well in a demo.

How good the editing experience actually is. Your team will spend hundreds of hours in the editor. If it’s slow, confusing, or fights them, that cost is enormous and invisible on any spec sheet. Test this with the actual people who’ll use it, on a real task, before deciding. It’s the most important thing and the least measured.

Whether it fits your team’s technical level. A powerful developer-oriented CMS given to a non-technical team is a daily obstacle. A simple CMS given to a team with complex needs becomes a cage. Match the system to the people, not to the impressiveness of the feature list.

How it handles growth. The system that’s fine for fifty pages and one site can buckle at five thousand pages across ten markets. If you’ll grow, test whether the CMS grows with you, because migrating later is painful and expensive.

What it’s like to get your content out. This is the one nobody checks until it’s too late. If leaving means your content is trapped in a proprietary format, you’re locked in, and lock-in eventually costs you either money or a horrible migration. Ask how export works before you commit, not after.

Total cost, not licence cost. The sticker price is a fraction of it. Implementation, training, developer time, hosting, and the ongoing cost of a system that slows people down all add up, and they dwarf the licence. A cheap CMS that needs constant developer help is expensive. A pricier one your team flies in can be the bargain.

A selection worksheet

The decision rests on your team’s technical level, how you’ll grow, and the daily editing experience, far more than on which product has the longest feature list.

We’ve put it into a short selection worksheet: space to record who actually edits and their technical comfort, the real tasks to test in any demo, a growth check for where you’ll be in three years, an export-and-exit question, and a total-cost comparison that includes the lines beyond the licence. The most valuable page is the editing test, so do that one with your real editors on a real task, not with the vendor driving.

The same team, two CMSs

Abstractions about “fit” land better with a concrete pair, so here’s one small marketing team living with two different choices.

The team is four people. None of them write code. They run a company website, publish a couple of blog posts a week, update product pages when things change, and occasionally build a campaign landing page. That’s the whole job.

Give them a traditional all-in-one CMS and their week is smooth. They log in, write a post in an editor that looks roughly like a word processor, drop in images, hit publish, and it’s live. Building a landing page means picking a template and filling it in. When they want to change a headline, they change it and save. They almost never talk to a developer, which is exactly the point, and the system’s lack of deep flexibility never comes up because they never reach for it.

Give the same four people a headless CMS because someone read that headless is the modern choice, and their week is worse. The content editor is fine, but there’s no built-in way to see the page, because presentation lives in a separate front end that developers own. Publishing a post works; building a new landing page means asking a developer to build the front end for it. Changing how something looks is a developer task. The team that was independent on the traditional CMS now waits on engineering for things that used to take minutes. The headless system isn’t worse in the abstract, it’s worse for them, because they don’t have the developers it assumes and don’t need the flexibility it provides.

Now flip it. Take a team that publishes to a website, a mobile app, and in-store screens, with developers on hand, and give them the traditional all-in-one. Now they’re fighting the system, because it wants to produce websites and they need to feed three different surfaces. The headless CMS that punished the small team is exactly right for this one.

Same two products, opposite outcomes, and nothing about the products changed. Only the fit did. That’s why “which CMS is best” is the wrong question, and “which CMS is right for us” is the one worth answering.

Signs you’ve outgrown yours

If you already have a CMS, a few signals tell you it’s become the problem rather than the solution.

Simple changes need a developer. If updating a page reliably means raising a ticket and waiting, your CMS has stopped doing its one job, which was to let non-technical people manage content.

Your team avoids it. When people build things outside the CMS, in documents or separate tools, because it’s easier than using the system, that avoidance is telling you something loud.

It can’t do what you now need. New channels, new markets, new content types the system wasn’t built for. Outgrowing a CMS as you grow is normal and not a failure, just a signal.

Every change feels risky. If people are afraid to touch it because things break, the system is working against you.

None of these on their own means replace it tomorrow. Several of them together means it’s worth costing out the alternatives, because the hidden cost of a CMS your team fights is usually larger than the visible cost of changing.

The stuff worth remembering

A CMS is software that lets non-technical people manage a website without writing code. That’s its whole reason to exist.
It separates content from presentation. How tightly it binds the two is what makes a CMS traditional, headless, or hybrid.
Traditional all-in-one suits most marketer-run websites. Headless suits multi-channel teams with developers. Match the type to your situation, not to fashion.
SaaS is the sensible default for most teams. Self-hosting is for specific control or compliance needs with the people to handle it.
The editing experience is the most important factor and the least measured. Test it with your real editors on a real task.
Check how you get your content out before committing. Lock-in costs you later, either in money or a painful migration.
Judge total cost, not licence cost. A cheap CMS that needs constant developer help is the expensive one.

Not sure which CMS fits your team?

From here it is worth seeing what a headless CMS adds, how to choose the right CMS, and how a CMS compares to a DXP.

The useful version of this conversation starts with who edits your content and how technical they are, not with a shortlist of products. If you’d like a second opinion on which type suits your situation, or whether the CMS you have is worth keeping, get in touch and we’ll work through it with you.