'Headless CMS' is currently one of the most fashionable phrases in web development, and like most fashionable phrases, it gets recommended far more often than it's actually the right answer. Founders are told they need one without ever being told what it is or what it costs them. The result is teams taking on real complexity for benefits they'll never use.
This is a decision worth understanding properly, because choosing headless when you don't need it can double your build cost and slow down every future change. Here's the honest version.
The 'head' and the 'body'
A traditional CMS like standard WordPress does two jobs in one package: it stores your content (the 'body') and it decides how that content looks on the page (the 'head'). They come welded together.
A headless CMS chops the head off. It keeps the body — managing and storing your content as pure data — and hands that content to a separate front-end via an API. A developer then builds the 'head' however they like to display it.
The analogy: a traditional CMS is a meal kit that arrives cooked and plated. A headless CMS delivers the ingredients, and your chef decides what to make — more work, but you can serve the same ingredients as a starter on the website, a main on the app, and a snack on a digital display.
Why developers like it
- One content source, many outputs. Write content once and publish it to a website, mobile app, in-store screen or partner site — all pulling from the same place.
- Performance. The front-end can be built as a fast, modern app and served from a CDN, which often produces excellent Core Web Vitals scores.
- Security. With no public admin login bolted onto the live site, there's a smaller surface for attackers.
- Freedom. Developers aren't constrained by a theme system; they build exactly what's needed.
The costs founders don't hear about
The pitch usually stops at the benefits. Here's the other side, which matters just as much.
| Consideration | Traditional CMS | Headless CMS |
|---|---|---|
| Build cost | Lower | Higher |
| Developer skills needed | Widely available | More specialist |
| Content preview | Seamless | Sometimes fiddly |
| Plugins / quick add-ons | Abundant | More custom work |
| Multi-channel publishing | Limited | Excellent |
In practice, headless typically means a higher upfront build, a smaller pool of developers who can maintain it, and more custom work for features that come 'free' as plugins on traditional platforms. For a single marketing site, that's a poor trade.
When headless is the right call
You publish everywhere
If the same content needs to appear on your website, a mobile app and perhaps other surfaces, managing it in one headless source beats maintaining three copies.
Performance is mission-critical
For high-traffic sites where speed directly drives revenue, the performance ceiling of a well-built headless front-end can justify the extra effort.
You have the right team
Headless rewards teams comfortable with modern front-end development. If your agency or in-house developers work this way already, the overhead is lower.
A simple gut check: if you can't name at least two distinct channels your content needs to reach, you probably don't need headless yet.
When to stick with traditional
If you run one website, your content is mostly pages and blog posts, your team values easy editing and quick add-ons, and budget matters — a traditional CMS wins comfortably. There's no prestige in over-engineering. Many successful businesses run beautifully on standard WordPress and would gain nothing from going headless except a bigger invoice.
Deciding well
The right answer depends on where your content needs to go and what your team can realistically maintain. Be wary of any provider who recommends headless without first asking about your channels, budget and maintenance plans — that's a sign they're selling an approach, not solving your problem.
To get a balanced view, brief two or three agencies and compare their reasoning. Experienced web development specialists in our directory can map your needs to the simplest architecture that does the job — which is usually the right one.