The headless CMS conversation has matured considerably in the past few years. What was once the domain of enterprise web teams with large engineering budgets has become accessible to organisations of almost any size. That's a good thing. But it's also produced a surge of headless implementations that weren't the right fit — expensive projects that delivered less flexibility than promised and more complexity than anticipated.
What Makes It Headless
A traditional CMS couples the content management backend with the presentation layer — the "head" — that renders it. A headless CMS separates them. Content is managed in one place and delivered via API to whatever front-end consumes it: a website, a mobile app, a digital sign, a voice interface. The separation creates genuine flexibility for organisations delivering content across multiple channels.
When It's Worth It
Headless makes sense when your organisation genuinely needs content delivered across multiple channels, when your development team has the capability to build and maintain the front-end layer, and when the flexibility to choose your own rendering technology is a real strategic need rather than a theoretical one.
When It Isn't
For organisations with a single web channel, limited engineering resources, or content teams that need to preview and publish quickly without developer involvement, headless often creates more problems than it solves. The speed and flexibility it promises require investment in engineering that many organisations underestimate.
The right question isn't "should we go headless?" It's "what does our content architecture need to do, and what's the best tool for that job?" A Headless, Composable and SaaS Audit helps answer that question with specificity rather than trend-chasing.