The Headless CMS Guide: what it is, when it makes sense, and what it costs

A headless CMS stores your content as structured data and serves it through an API, while the front end that visitors see is built and hosted separately. You should consider one only when three conditions hold at once: your content is genuinely structured, it needs to feed more than one surface, and someone with engineering capability will own the front end for years, not months. This guide covers how the architecture works, when it earns its cost, when it's the wrong call, and what running one involves, drawn from running our own site on exactly this stack.

First, the vocabulary, because the category is drowning in it. "Headless" means the CMS has no presentation layer: no themes, no page builder, no rendered website. It's a content database with an editing interface and an API. The front end (a "head") is whatever you build to consume that API, typically a modern web framework. "Decoupled", "composable", and "API-first" are marketing variations on the same idea. Sanity, Contentful, and Strapi are well-known platforms in the category; the concepts in this guide apply to all of them.

The framing before we go deeper: headless is a genuinely excellent architecture that is wrong for most small and mid-sized businesses. Both halves of that sentence are true, most vendors only tell you the first half, and knowing which half applies to you is worth more than everything else in this guide.

In a traditional CMS, content and presentation are one bundle: the system editors type into is the system that serves the website, pages are pages, and the theme decides what everything looks like. In a headless setup, the pieces come apart into three layers.

• The content model: your content types defined as fields. A case study is a client, a sector, a problem, the work, an outcome with numbers, and a quote. An article is a title, a dek, a body, an author reference, and its metadata. The model is the real intellectual work of a headless build, and it's where most of the long-term value lives
• The editing environment: where humans create and manage content against that model. Modern platforms make this pleasant, with structured forms, live previews, drafts, and roles
• The front end: a separately built application that queries the API and renders the content. This is real software, written and maintained by developers, and it can be anything: a website, several websites, an app, an internal tool, all drawing from the same content

The separation is the feature. Because content is just data, the same case study can render as a page on your site, a card in a grid, a slide in a generated proposal, and a clean quotable claim for an answer engine, from one source, with no copy-pasting and no drift. Change the design and the content doesn't move; restructure the content and the API contract tells the front end exactly what changed.

The separation is the feature, and the separation is the cost. Every layer you decouple is a layer someone maintains.

And the same separation is the cost. There's no theme to install, no visual editor rescuing a non-technical team, and no page that exists until someone writes the code that renders it. Every benefit in this chapter is purchased with engineering time, at the start and forever.

Headless earns its cost when three conditions hold at the same time. One or two out of three is how expensive regrets get built.

• Your content is genuinely structured: repeating types with consistent fields, at real volume. Products, articles, listings, locations, case studies, documentation. If your site is twelve bespoke pages, there's nothing for the model to model
• The content feeds more than one surface, now or credibly soon: a site plus an app, plus internal tooling, plus generated documents, plus whatever ships next year. Single-surface content rarely justifies the architecture
• Engineering capacity exists and is owned: in-house developers or a genuinely long-term contracted team, on the hook for the front end in year three, not just launch week. This is the condition that disqualifies most businesses, and it should

There's a fourth factor that's newly weighty: machine readers. Answer engines lift claims most readily from structured content, and a headless CMS is structure all the way down, every fact a labelled field, every page assembled from data. If AI visibility is a strategic priority and the other three conditions hold, headless compounds the strategy: your content model and your citation strategy become the same artefact. It's a genuine advantage. It is not, on its own, a reason to adopt the architecture, because most of the machine-readability benefit comes from modelling content as fields, which the next chapter's alternatives also provide.

The profile that fits, in one sentence: a business that treats its website as software, its content as an asset feeding many surfaces, and its developers as permanent staff rather than a launch-week expense.

The wrong reasons to go headless are more common than the right ones, so they deserve their own chapter.

• Because a developer prefers it. The most common path to a regretted headless build: a capable developer builds a beautiful stack, then changes jobs, and the business discovers that changing a testimonial now requires a contractor. If the maintenance plan is one person's enthusiasm, the architecture is a liability with good performance scores
• Because it's modern. Architecture fashion is real and expensive. Your buyers cannot tell what CMS you run; they can tell whether your site is current, fast, and true, and a marketing team locked out of its own website produces a site that is none of those
• For a marketing site owned by marketing. If the people who touch the site weekly are marketers shipping pages and campaigns, a visual platform is simply the better tool. Webflow's CMS stores content as structured fields too, which captures most of the machine-readability benefit, while your team ships changes in minutes without a deploy queue

This is where we put our approach on the record: we build on Webflow, Shopify, and Sanity headless, and which one you get is decided by your situation, not our preference. For a marketer-owned brochure site with no engineering ownership, we'll recommend Webflow and tell you plainly that headless would be a liability for you. For a business with the engineering capacity to sustain it, we'll recommend and build headless on Sanity, because over the long run it's often the better call. The discipline isn't in refusing to build headless. It's in refusing to sell it to someone who can't maintain it, and being equally clear when it genuinely is the right architecture for you.

The best idea in headless is available even when headless is wrong: model your content as structured fields, whatever platform you're on.

And if you take one thing from this guide without spending a dollar, take the underlying idea. Content modelled as structured fields is the source of most headless benefits (consistency, reusability, machine readability), and it's available on a visual platform for a fraction of the cost. The structure is where the value lives. The architecture is just one way to get it.

Headless costs arrive in three instalments, and the sticker price is the smallest of them.

• Platform fees: the CMS itself. Most platforms, Sanity included, have free or cheap tiers that genuinely cover a small business, scaling to hundreds of dollars a month with team size, usage, and enterprise features. Hosting for the front end adds a similar order of magnitude. For most businesses at this scale, the software line is noise
• The build: this is where the money is. A headless site is a custom software project: content modelling, front-end development, editorial tooling, previews, integrations. Credible builds start around the top of ordinary website pricing and climb well past it, which is to say $30,000 as a floor for anything serious and comfortably six figures for large or complex builds. Anyone quoting headless at template-build prices is leaving out the part where software gets built
• The ownership: the permanent line. Dependency updates, framework maintenance, the occasional migration, and developer time for every layout change, forever. Budget real engineering hours every month, whether in-house salary or a contracted arrangement. This line is the real price of the architecture, and it's the one missing from every vendor comparison table

Compare that shape against the alternative: a Webflow build sits at $10,000 to $50,000 with platform fees in the tens of dollars monthly and near-zero mandatory engineering. The comparison isn't about which is cheaper, because they're different products. It's about whether the multi-surface, structured-content, software-grade benefits in chapter three are worth an engineering payroll to your specific business. For most, no. For the right few, emphatically yes.

The site you're reading runs headless: Sanity holds every article, guide, service, and page as structured content, and a custom front end renders it. We're a fitting case for it on all three conditions from chapter three: we have engineering capacity in-house, our content feeds multiple surfaces, and our content is structured to the field level because our AI visibility strategy depends on it. It's also the stack we build for clients whose situation meets the same test.

What the architecture does for us day to day: content is published into the model through our own internal tooling with human approval before anything goes live. Facts stay consistent because they exist once, as data, rather than pasted across pages. Every guide chapter and article is answer-first and machine-liftable because the model enforces the structure. And when we add a surface, the content is already waiting for it. None of this is hypothetical; it's the workflow that produced the page you're on.

What it costs us is exactly what chapter five promised: we maintain software. Schema changes are treated as versioned contracts between the content and the front end, deployments are engineering work, and there is no visual editor to hand a marketer. We pay that cost knowingly, and when we build headless for a client, we make sure they either carry that same capability or have us carry it for them under an arrangement that's upfront about the ongoing cost. Headless without a maintenance plan is the one version we won't ship.

The decision, condensed: if your content is structured, multi-surface, and backed by real engineering ownership, headless is a superb architecture, we build it on Sanity, and we'll recommend it without hesitation. If any of those three is missing, we'll build you a site on a platform your team can drive, and revisit headless when the conditions change. Either way, the first call is free, and the recommendation you'll get is the one we'd give ourselves in your position, because the architecture should follow your requirements rather than our preference.