Shopping for a Headless CMS: A Field Guide to the Decoupling Economy

The signals of an industry forming are all present and dated. Contentful closed its Series D this summer at prices that make content infrastructure a venture category. Gatsby has turned static-site generation from a hobbyist practice into a funded framework with a commercial roadmap. And next month the first JAMstack Conf convenes in New York, giving the architecture a conference. In this industry, that is how a technique announces it has become an economy.

The headless CMS, content managed in one system, delivered as structured data through APIs to whatever front ends consume it, has traveled the full distance we have tracked since its cautious 2015 review. From curiosity, through the platform convergence (WordPress’s API in core, AEM’s content services), to a vendor marketplace with sales teams.

The buyer questions arriving have shifted to match, from ‘what is headless’ to ‘which one should we buy.’ Which is exactly the moment a field guide merits its place, because vendor marketplaces are built to skip the question that should gate all the others. This guide is assembled from the evaluations we have actually run this year, and it puts the gate back first.

The requirements gate, before any vendor demo

The question that decides headless evaluations before feature matrices matter. What, exactly, do you need to deliver that a normal architecture delivers poorly?

The honest reasons are structural and countable. Genuine multi-channel delivery: the same content feeding web, apps, kiosks, and partners. App-parity needs, where a native app must render identical content on identical schedules. Content-as-data ambitions: syndication, personalization engines, the structured reuse our fragments coverage describes. And certain high-scale setups where pre-rendered delivery matters. Those are real, we build for them, and headless serves them well.

The reason that fails the gate, stated with the bluntness a field guide owes its readers. ‘Our developers prefer React’ is not a requirement. It is a preference. It is legitimate as a preference. And it is routinely laundered into architecture decisions, where it silently prices the editorial team’s daily working conditions. That is the trade the next section itemizes.

The gate question exists because most institutional websites are, per the standing view we have held since 2015, content sites with one primary channel. For them the complexity is purchased and the benefits are hoped for. Requirements first. Always requirements first, and in writing, because the demo is designed to make everyone forget them.

The genuine differentiators, from this year’s evaluations

• Editorial experience, still the weak flank. The gap between vendors is widest exactly where the demos spend the least time. Preview: can an editor see the page before publishing, across the front ends that render it? Workflow: drafts, review states, scheduling, per the bar our CMS coverage sets. And layout freedom: can editors compose landing pages, or does every layout change become a developer ticket? These range from decent to punishing across the current market, and the punishing tier recreates the ticket-queue disease the enterprise file spent years documenting. Evaluate with your actual editors doing their actual Tuesday tasks. Their verdict outranks the developers’, because they live in the system daily.

• Pricing models, structurally different. The SaaS tier prices by entries, API calls, seats, and environments. Sites should model their real content volumes and traffic against the tier tables before falling in love. The pleasant starter tiers and the at-scale invoices are different documents. The alternative economics (headless WordPress or Drupal, the familiar platform as API backend) trade subscription fees for hosting-plus-maintenance and keep the editorial tooling. For many sites, they remain the math winner.

• The rebuilt-for-free tier. What normal platforms include that headless builds must recreate at project cost. Preview plumbing. Redirects. Forms. Search. Media handling. The unshowy middle of every site. The line items are small alone and decisive together, and the honest total-cost comparison includes them. Vendor comparisons reliably do not.

The updated position, and why hybrid keeps winning

Our position, revised in public.

Since 2015: the ‘when’ for headless has genuinely grown. The vendor tier matured. The tooling grew up. The multi-channel needs it serves became more common. Our own project mix shows it. More API-fed features, more decoupled components, more builds where content travels beyond the page.

Unchanged: for the marketing-site majority, full decoupling still means buying back your editorial experience at a premium. The purchase should be made knowingly or not at all.

And the finding from this year’s evaluations that deserves the weight of a verdict. Hybrid setups keep winning the evaluations the pure plays frame as either-or. The coupled CMS delivers its primary channel normally, while feeding APIs where real consumers exist. The app, the portal, the signage network. That captures most of headless’s real value at a fraction of its cost. It keeps the editorial freedom the institution’s daily work depends on. And it holds the exit rules’s favorite property. It can be undone.

The platforms themselves converged on this position. That was the entire architecture story of 2016 and 2017. The evaluations confirming it are simply the market catching up to its own plumbing. The pure headless build has its cases, and we bid them happily when the gate question passes. The gate question, mostly, does not pass, and a field guide that pretended otherwise would be a brochure.

A note on evaluating new markets

A method note to close, because it outlasts this market cycle. When a technique acquires an economy (funding rounds, conferences, sales teams) the buyer’s diligence burden goes up precisely as the discourse’s neutrality goes down. The architecture conversation is now also a market conversation. Every ‘is headless right for you’ resource is increasingly written by someone whose answer is priced in.

The antidote is the same method we apply to every category. The durability rubric for frameworks. The governance questions for enterprise suites. The requirements gate here. Write the requirements before the demos. Test with the people who will live in the system. Model the costs at your real scale. Keep the exit surveyed.

The decoupling economy will produce excellent tools, real failures, and a great deal of content marketing. The organizations that thrive through it will be the ones that remembered a CMS is bought for a decade, not a conference season. Requirements first. The rest is buying hygiene.