Over the last little while, I’ve had the chance to spend a lot of time inside different CMSes. Not just skimming docs or watching demos, but actually building something small and real with them.
As part of a broader evaluation, I revisited six CMSes I already had experience with, some recently, some not so recently, and explored a handful of others more lightly. To force myself out of abstract comparison mode, I built the same small site multiple times. I prototyped the idea first, then implemented it across each system. I leaned on AI heavily to move faster, and over the course of about a week, I ended up with a set of scrappy but functional proofs of concept.
What surprised me wasn’t how different these systems were. It was how similar many of their ambitions have become.
Most of the CMSes I evaluated deeply were headless. That wasn’t accidental. Headless was a hard requirement for the context I was working in, for a variety of migration related reasons.
As I spent more time inside these tools, something kept catching my attention. Almost every headless CMS I touched was investing heavily in some form of visual editing or live preview. Some had already built it. Some were actively reworking it. Some were clearly racing toward it.
That struck me as interesting.
The original promise of headless CMSes is that content and presentation should be decoupled. Editors focus on content. Developers focus on rendering. Content becomes portable, reusable, and adaptable to many different outputs.
Conceptually, this makes a lot of sense. Especially if you imagine an organization with a truly diverse set of surfaces. A marketing website. A web app. A mobile app. A kiosk. Digital signage. Maybe even hardware.
In that world, it’s reasonable to think about content as something that exists independently of how it looks anywhere in particular.
But once you get into the day to day reality of how most organizations work1, that model starts to feel a bit fragile.
Yes, there are some kinds of content that genuinely travel well. An announcement banner is the example I keep coming back to. A short sentence. A call to action. That kind of content can live almost anywhere with very little adaptation. Website. App. Notification. Screen on a wall. The same is often true for product data, things like names, prices, SKUs, or availability. This information is primarily data, not presentation, and different surfaces can consume it and render it in ways that make sense for their context.
But most content isn’t like that.
The way you write and structure something for a website is often different from how you’d write it for a mobile app. Which is different again from how you’d design it for a kiosk or a constrained interface. The medium often shapes the message, whether we want it to or not. Length, hierarchy, emphasis, even tone all shift based on where something is going to appear.
So while we like to talk about universal content, I’m not convinced most organizations actually have that much of it.
And for a lot of companies, they don’t even need to solve for extreme multi surface complexity. Take a typical SaaS company. They might have a marketing site, a web app, a mobile app, maybe a desktop app. All of these are still primarily web centric experiences. The mobile and desktop apps diverge the most, but even then, they’re not radically different worlds.
In that context, do you really need a fully headless CMS to manage content across those surfaces? Sometimes the answer is yes. Often, I’m less sure.
I think the headless CMS vendors are running into this tension in practice. Decoupling sounds clean and elegant. But editors don’t experience content in the abstract. They experience it as something that appears somewhere, for someone, in a particular shape.
When you remove presentation entirely, you also remove the feedback loop that helps people understand whether what they’re creating makes sense.
Which might explain why so many headless CMSes are now trying to reintroduce that loop. Live previews. Visual editors. Embedded rendering. Ways to see content in context while you’re working on it.
In other words, finding ways to bring the presentation layer back into the editing experience, without fully giving up the architectural benefits of headless.
As I was working through these systems, I kept thinking about CMSes that offer a more hybrid model. Systems that can handle both content and presentation together, but don’t force you to couple them if you don’t want to. You can go fully decoupled. You can go fully integrated. Or you can sit somewhere in between.
For many marketing teams, that flexibility feels genuinely valuable. Not because it’s theoretically pure, but because it maps more closely to how teams actually work. Designers and editors often want to think in terms of pages and layouts. Developers want structure and APIs. Both can coexist, if the system allows for it.
The usual counterargument is scale, performance, and operational complexity. Hybrid systems are often not fully managed platforms. You need to care about hosting, caching, upgrades, and infrastructure. Or you need to partner with someone who does.
Meanwhile, fully managed headless vendors handle all of that for you. They control the CMS and the platform it runs on. Their systems are tuned for their specific use cases. And that’s real value.
But that also means that some of the tradeoffs we attribute to a CMS are actually platform level decisions. Performance. Scalability. Reliability. Those are not inherent properties of content models or editors. They’re properties of how the system is deployed, operated, and maintained.
Seen through that lens, it makes sense that headless CMS vendors are evolving in the direction they are. They’re responding to what users are asking for. A way to think about content in context. A way to see what they’re making. A way to reduce the cognitive gap between editing and outcome.
None of this feels like a failure of the headless model. I actually really like the headless model (just maybe not for the reasons it’s normally marketed for). It feels more like an adjustment. A recognition that while the idea of fully decoupled content is appealing, the reality of most content work is messier, more contextual, and more human.
I don’t think there’s a single right answer here. There are absolutely cases where headless is the right choice. There are cases where it’s overkill. There are cases where a hybrid approach unlocks the best of both worlds.
What I came away with most strongly wasn’t a verdict, but a pattern. A noticeable convergence. A lot of different systems, starting from different philosophies, all inching toward the same question.
How do we give people the benefits of structured, flexible content, without taking away their ability to understand what they’re actually creating?
I don’t think we’re done answering that yet, as an industry.
- Yes, there ARE content-as-API shops, I just haven’t found them to be as common as many claim them to be. ↩︎
Leave a Reply