Ask which headless CMS to use and you’ll get a dozen confident, contradictory answers — Sanity, Contentful, Storyblok, WordPress running headless via its REST or GraphQL API, or a git-based option like Astro’s own content collections. The honest answer is that for most teams the platform matters less than three decisions underneath it: who edits content and how often, whether the frontend needs that content at build time or at request time, and how much you’re willing to pay in licensing or engineering time to get it. Get those right and several platforms will serve you well. Get them wrong and the “best” CMS on paper will still feel wrong in production.
Headless just means the CMS doesn’t render your pages
A headless CMS stores and serves content; it has no opinion about how that content looks. Traditional WordPress couples the two — the theme that renders your page lives inside the same system that stores your posts. Headless architecture splits them: content lives in the CMS, a separate frontend (Astro, Next.js, whatever you’re building with) fetches it and decides how to render it. That split is why headless has become the default for serious builds — it lets the frontend be as fast and as tightly controlled as you want, independent of what the CMS vendor ships. We’ve written before about comparing WordPress against a headless approach in more depth if that’s the fork you’re standing at.
The real decision is build-time vs. request-time content
Most of the platform debate collapses once you separate “when is content fetched” from “which vendor stores it.” Some frontends fetch content at request time, over an API, on every visit — flexible, but it adds a network round trip (and a point of failure) to every page load. Others pull content at build time, bake it into static HTML, and serve it from a CDN with nothing left to fetch. A newsletter that publishes twice a week doesn’t need request-time freshness; a live pricing feed does. Most marketing and content sites are the former, which is exactly why static-first delivery — content resolved once at deploy, not re-fetched on every visit — is our default rather than an optimisation we bolt on later.
Editor experience is a business requirement, not a nice-to-have
The CMS with the cleanest API is the wrong choice if the person publishing content dreads opening it. A marketing team that needs to update a page weekly needs a genuinely usable editing interface, sensible preview, and a content model that maps to how they actually think about the page — not a JSON blob they have to reverse-engineer. This is the part engineers most often under-weight, because they’re not the ones using the interface day to day. Sit the actual content owner in front of the shortlist before deciding; their reaction is more predictive than any feature comparison chart.
Don’t pay for scale you don’t have yet
Enterprise headless platforms price for enterprise problems — multi-region editing, complex approval workflows, huge content volumes — and it’s easy to pay for that scale long before you need it. For a straightforward marketing site, a simpler platform (or, for content that changes rarely, a git-based workflow with no separate CMS at all) is usually enough, and it’s easier to migrate away from later precisely because you never built deep dependencies on vendor-specific features. Our own Launch tier builds — fixed scope, from £5,000 — include a CMS sized to what a small team actually needs to keep content current, not what a platform would like to sell alongside it.
None of this is really a CMS decision first — it’s a decision about your content and your team, with the CMS chosen to fit. If you’re weighing this up for a new build or a migration off a platform that’s stopped fitting, that’s exactly the conversation our web development team starts with.