Selecting a CMS is rarely about picking a nicer editor UI. In my experience, the decision is mostly about where complexity will live once the project is real: integrations, data flows, content structure, and the operational glue work nobody demos.
A CMS decision is rarely about the user interfaces. It is a decision about system boundaries, integration complexity, and who owns the operational scaffolding. Getting those boundaries wrong is the primary reason I see CMS projects fail.
In my experience, much of the CMS conversation is driven by marketing rather than delivery experience. I use headless systems, and I like some of them, but I do not accept “headless” as an automatic upgrade or more "modern". I treat it as a trade: I gain freedom in the presentation layer, but I often buy myself integration and orchestration work elsewhere.
What I Mean When I Say “CMS”
When I say “CMS”, I mean a system with three distinct parts:
- Presentation layer: the website (or other experience) that users actually see. This is usually where custom design and brand work lives.
- Admin interface: where editors create and manage content. This tends to be less customizable in look and feel, even when the system is flexible.
- Content storage: something that persists content between the admin and the presentation. That is often a database, but I have seen file-based storage or “storage by API” where another party owns persistence.
A CMS decision is not a UI decision. It is a decision about boundaries: what lives inside the CMS, what lives outside, and how many moving parts must cooperate for a page to ship. Most CMS pain I see comes from underestimating those boundaries, not from choosing the “wrong” editor screen.
Headless vs. Composable
The headless pitch is consistent: unlimited freedom in the presentation layer, and the ability to publish the same content to many channels (web, mobile, in-store screens, and so on). The correct version of the story is that the CMS stops taking responsibility for the frontend entirely and becomes just an API.
The multi-channel story is a good one, but unfortunately I have rarely seen it working out the way it sold. The reality that comes with it is what I call “channel-copy drift” — when the promise of “publish once, display everywhere” gets undermined by the fact that content is almost always rewritten per channel. A paragraph that works on a website often becomes a shorter snippet in a mobile context, and the structure that makes content useful in one channel can be wrong for another. The result is that “one piece of content” turns into a family of similar-but-not-identical variants, and the CMS model has to reflect that anyway. I saw this happen with a clients who was sold a headless approach for a mobile app and planned to use the same content for the website. The team quickly realized the website needed longer, more complete copy than what the mobile app required — illustrating that “publish once, display everywhere” broke down in practice.
Composable, as I use the term here, is a different stance. The goal is that the CMS orchestrates a website made up of all the systems a business already depends on. The CMS becomes a coordinator, not just a database of content.
When I see headless projects struggle, it is often because the architecture is treated as “simple” while the integration surface silently expands. Headless can be a good fit for websites with a short lifespan, limited complexity, or where the development team primarily has frontend development experience.
If a business needs to integrate with systems like a PIM, a CRM, or other third-party platforms, someone has to decide where synchronization happens and how failures are handled. In many headless setups, that work ends up outside the CMS: custom services to pull, push, transform, retry, and reconcile data. That is not inherently wrong but it is expensive in build time and operational ownership.
Composable CMS platforms frequently reduce this pain by shipping with more operational tooling in the core product. In practice, the difference I notice is not philosophical. It is whether the system already has capabilities for “real world” work:
- Queue management and job processing
- Retry and failure handling
- Logging and debugging
I have seen teams move faster when those capabilities are built in, because they can start integrating without first building an integration platform. Tools like Craft CMS, Enonic, and Umbraco often feel more completed, where the software vendor takes responsibility for more than being a database.
This is not a claim that Headless CMSes cannot do it. It can. The point is that headless makes it our job to assemble the tools.
Editorial Preview and Workflow
Headless CMS platforms are not responsible for the presentation layer, so there is no built-in default functionality for previewing content before publication. Most headless systems have ways to deal with preview, but it requires custom development in the presentation layer.
I find it strange that many headless CMS vendors have developed specific SDKs to support presentation layers despite having chosen not to ship the presentation layer. If a headless CMS needs to ship an SDK for the frontend, I believe it would be equally reasonable to just ship a supported official presentation layer with the CMS. Composable CMS platforms like Enonic, Craft CMS, and Umbraco provide preview functionality out of the box when using the bundled presentation layer, making it cheaper and less time-consuming for developers with no extra work needed.
Hosting and Single Points of Failure
Headless CMS architectures introduce at least two single points of failure: the frontend framework hosting and the CMS itself. Hosted headless services like Sanity and Contentful cannot technically be co-hosted with the presentation layer. Open-source headless platforms like Strapi and Payload can be self-hosted alongside the presentation layer, but not on popular services like Vercel that many teams use for frontend hosting.
Composable CMS platforms deploy the CMS and presentation layer as one unit, meaning one hosting environment and one point of failure. I acknowledge the trade in a composable setup, I cannot change one without changing the other, but realistically, the CMS and presentation layer are almost always changed together anyway.
Caching Responsibility
In a headless setup, caching is another thing we must assemble. Deciding how and when content is invalidated across the CDN, the API layer, and the frontend.
In a composable system, cache invalidation is handled closer to the CMS because the CMS knows when content changes and owns the presentation layer, so it can invalidate more precisely. This ties into my recurring theme of who is responsible for the operational glue work. I acknowledge that caching remains one of the harder problems regardless of architecture. The composable advantage is not that caching becomes easy, but that the team does not have to build the invalidation infrastructure from scratch.
Upgrade Responsibility and Version Compatibility
In a headless setup, the CMS and the frontend framework are on separate release cycles with no coordination between them. When either side introduces breaking changes, the team is responsible for discovering and resolving the incompatibility. I cannot automatically assume a new version of a headless CMS will work with the existing frontend, and vice versa.
Testing in a headless setup must cover the integration boundary on every upgrade of either system — something easy to overlook until it breaks in production. In a composable setup, the vendor owns both sides and takes responsibility for the upgrade path, providing information and guidance when breaking changes are introduced.
SEO and Metadata Management
In headless setups, things typically taken for granted like sitemap.xml and other SEO tooling are simply not there. It must be built from scratch in the presentation layer. This applies not only to sitemaps but to all types of SEO optimization that require CMS content, all must be developed in the presentation layer.
In composable CMS platforms, this is usually handled by the CMS itself or by third-party plugins that tie directly into the presentation layer, since there is normally only one presentation layer in a composable CMS.
Content Structure
I do not spend much time arguing about which admin interface “feels” better. That is subjective, and different editorial teams value different things.
What I do care about is how content is structured and navigated at scale. Some headless systems like Contentful lean hard into the idea that content has no hierarchy: everything is a set of objects and references. That can be elegant in small demos. In large installations, I have seen it become a navigation problem for humans. When editors are faced with thousands of entries, a flat universe of “documents” can turn into a memory game: naming conventions, filters, and search become the only map.
When reviewing CMSes I ask to see a real project, not a demo space. I want to see the admin interface with messy content models, filled with legacy decisions. That is where content architecture either supports editors or slowly punishes them.
This is also where composable versus headless becomes less important than content modeling discipline. A composable CMS can still be chaotic if the model is chaotic. A headless CMS can be usable if the model and navigation patterns are intentionally designed. The system does not save a team from unclear taxonomy.
Relational vs. Document-Based Content
One of the most useful lenses I bring into CMS selection is whether the majority of content behaves like “records” or like “documents”. I think of it as row-based versus document-based content.
Row-based content tends to look like structured entities with clear fields and relationships. In my experience this aligns well with SQL-shaped thinking: products, locations, employees, specifications, pricing tables, and other data that wants constraints and predictable querying.
Document-based content behaves more like pages, articles, and narrative blocks: content that is edited as a whole, reviewed as a whole, and published as a whole. It can still be structured, but its primary unit is the document, not the record.
Most businesses have both. The choice is about which one dominates, and whether the CMS makes the dominant case easy without making the secondary case painful.
Summary of My Position
I do not treat Headless CMS as a synonym for “modern”. I treat it as a specific trade that can be worth it if I am prepared to assemble the integration and operational tooling around the CMS.
When the site must orchestrate multiple systems and the business needs background jobs, synchronization, and operational workflows, I often default toward Composable CMS platforms as a practical approach to how real projects behave once the demo is over.
The most reliable CMS selection work I do is not vendor comparisons. It is boundary setting: deciding what the CMS is responsible for, how content is structured, and where integration complexity will live when the project is running in production.
