How to choose a headless CMS

What "headless" actually changes

A headless CMS stores and edits your content but does not render it. Instead of the CMS owning templates, themes and the URL your visitor hits, it exposes the content over an API and a separate front end decides what to do with it.

Three things change the day you go headless, and only one of them is about the website.

The first is that your content becomes reusable. The same product description can feed the website, the mobile app and the partner portal, because none of them is privileged. The second is that your front end is no longer constrained by the CMS's template language — a Next.js or React application can be developed independently of the CMS templates. The third, and the one most teams underestimate, is that you now own the front end. Nobody ships you a new theme. Every layout is something a developer built, and someone has to maintain it.

That third point is the whole trade. Headless buys flexibility and costs you a permanent development relationship. If you have one brochure site, no app and no developer, that trade is a bad one.

Headless CMS vs WordPress: the honest comparison

WordPress powers a large share of the web and is not the wrong answer as often as agencies imply. Compare them on the things that actually differ:

• Editing experience. WordPress with a page builder gives a non-technical editor near-total layout control immediately. A headless CMS gives them the fields a developer defined, which is more consistent and less free.
• Front-end freedom. A conventional WordPress site uses PHP themes. WordPress can also run headless; a headless API can serve a front end written in any suitable language.
• Multi-channel. WordPress supports custom post types and API access as well as posts and pages. Compare how each candidate models your actual content, relationships and editorial workflows.
• Plugins. WordPress has an ecosystem for nearly everything. Headless platforms also offer plugins and integrations, including official and community Payload plugins. Check whether each feature is supported, needs integration work or must be built.
• Maintenance. Both approaches need updates, access control, backups and monitoring. Headless adds an API and a separate front end; security depends on their implementation and operation, not the label.
• Cost shape. Compare implementation, subscriptions, hosting, maintenance and change costs over the same period. A familiar theme can reduce initial work; a custom front end can increase it.

If the honest answer is "we need a good-looking marketing site and nothing else", a WordPress build or a site builder will serve you well and cost less, and we build those too. Headless CMS development earns its place when content has more than one destination, when the front end is doing real work, or when the content model is genuinely yours rather than posts-and-pages with custom fields bolted on.

Six questions that decide the choice

Run a shortlist through these before you look at a feature matrix.

• Where does the content go? One website, or a website plus an app plus a partner feed? More than one destination is the strongest argument for headless.
• Who edits it, and how often? Daily editing by non-technical staff needs a strong authoring experience, live preview and sensible validation. Even occasional editors need a workflow they can use without developer help.
• Hosted or self-hosted? A hosted API service removes operations work and adds a per-seat or per-record bill. Self-hosted keeps the data and the bill under your control and adds a server to run.
• Where does the content model live? Some platforms define fields in a web UI; others define them in code in your repository. Code-defined schema is reviewable in pull requests and reproducible across environments.
• What happens at renewal? Check what the price does when you add editors, locales, records or API calls. This is where hosted platforms surprise people in year two.
• Can you get your content out? Ask for the export format before you commit. A CMS you cannot leave is a strategic problem regardless of how good it is.

Hosted versus self-hosted

This is the fork that changes the most and gets discussed the least.

Hosted platforms — Contentful, Sanity, Storyblok and similar — run the CMS for you. You get an API, an editing interface and no servers to patch. Pricing may depend on seats, usage, features or plan limits, and your content lives in someone else's infrastructure, which matters for some UK data-residency and due-diligence conversations.

Self-hosted platforms — Payload, Strapi, Directus — run in your own infrastructure next to your database. You control hosting, data residency and cost, and you carry the operational responsibility. Even with an existing deployment pipeline, allow for backups, security updates, monitoring and recovery tests.

There is no universally correct answer. The question is whether your organisation would rather pay a subscription or run a service.

Where headless is the wrong answer

Be suspicious of anyone who never says this.

Headless is the wrong answer when you need a site live in two weeks with no developer involved, when the site is genuinely brochureware, when your team relies on a plugin ecosystem for shop, booking or forum functionality, or when nobody will own the front end after launch. Either architecture needs a maintainer; a custom front end also needs its own dependency and deployment maintenance.

When the real requirement is an application, scope the application first and decide what role a CMS should play. If most of what users do is logged in and transactional, you are building a web application that happens to have some content pages, and the CMS is a supporting cast member.

If that is where you land, say so early. A simpler content-managed build is work we do, and we would rather point you at the right shape than sell you the larger one. Tell us what the site has to do and we will recommend the setup that fits.

How we chose Payload for this site

We rebuilt scorchsoft.com on Payload CMS after seriously evaluating WordPress and MODX. The reasoning is written up in full in why we love Payload CMS, and the short version is relevant here because it is a worked example of the six questions above.

The deciding factor was where the content model lives. In Payload the collections, fields and blocks are TypeScript in the repository, so a schema change is a pull request with a migration attached rather than a click in an admin panel that nobody can review or roll back. That property turned out to matter more than we expected once AI agents entered the workflow: an agent can read the entire content model from the repository, and it still cannot publish a word without a human.

The trade we accepted was real. Payload has official and community plugins, but our site's content blocks and front-end presentation still needed implementation. Editors get the fields we defined rather than a free-form page builder. We consider that a feature, but it is a choice, and a team that wants to drag arbitrary layouts around would find it restrictive.

What a headless build costs and how long it takes

The CMS licence is usually the smallest number in the decision, but it is not always zero: check each platform's licence, paid features and eligibility conditions. The cost is the front end.

Work it out from four lines rather than a headline figure:

• The content model. How many distinct content types, and how many are genuinely different rather than the same shape with a different name.
• The number of layout components. A site built from twelve reusable blocks costs far less than one where every page is bespoke, and it is easier to edit afterwards.
• Migration. Moving existing pages, preserving URLs and setting up redirects is real work and is routinely left out of estimates. Getting it wrong costs search rankings.
• Integrations. Search, forms, analytics, CRM, payment — each is its own piece.

On our own builds we work in fixed two-week sprints, which makes the shape of the estimate visible rather than a single number at the end. Ask any supplier to break a quote down these four ways. That breakdown helps you compare what is included and where uncertainty remains.

A shortlist checklist

Before you sign anything, confirm you can answer these:

• Which content types you need, written down, before you compare platforms.
• Whether hosted or self-hosted fits your data and operations position.
• What the price does at three times your current content and editor count.
• Who builds the front end, and who maintains it in year two.
• How you export everything if you leave.
• Whether live preview works for the people who will actually edit.

Most bad CMS choices are not platform mistakes. They are a content model nobody wrote down and a front end nobody was assigned to own.