Headless CMS compared — Contentful, Sanity, Strapi, and when to skip them entirely

A headless CMS decouples content management from content presentation. Your content editors work in a clean, structured interface. Your developers query content via an API and render it however they like — in a Next.js frontend, a mobile app, a voice interface, wherever.

That flexibility is genuinely useful for certain types of projects. It's also overkill for many others, and adding a headless CMS to a project that doesn't need one adds ongoing cost, complexity, and dependencies without adding proportional value.

The case for going headless

You need a headless CMS when:

• Multiple teams need to manage content independently of the codebase
• The same content needs to appear on multiple platforms (web, mobile, email, etc.)
• Non-technical editors need to update content frequently, without developer involvement
• You need structured content models with validation, localisation, and content workflows
• You're building a content-heavy product where the content layer has its own complexity

If you have all of these, a headless CMS saves significant ongoing effort. If you have one or two, it might still make sense. If you have none, you're probably better served by MDX files, a Git-based CMS, or just a well-structured codebase.

Contentful

The enterprise option. Excellent API, good SDKs for every major framework, solid localisation support. The free tier is generous for small projects, but as soon as you scale content volume or need features like environments, custom roles, or advanced API access, costs escalate quickly.

Best for: Larger teams, projects with strict content governance requirements, businesses that need multi-environment content workflows (draft → staging → production).

Watch out for: Vendor lock-in. Contentful's content model is proprietary. Migration is painful if you ever need to leave.

Sanity

The developer-first option. Sanity Studio is fully customisable — the editing interface is itself a React application that you configure. Content is stored as GROQ-queryable JSON, and the real-time collaboration features are genuinely good.

Pricing is consumption-based, which makes it cheaper than Contentful for low-traffic projects and potentially comparable at scale. The query language (GROQ) takes some getting used to but is more powerful than GraphQL for most content use cases.

Best for: Technical teams who want full control over the editing experience, projects with complex content relationships, developers who prefer flexibility over convention.

Watch out for: The learning curve. Sanity rewards investment. It's not a drop-in CMS — you build the studio from scratch, which is powerful but time-consuming for straightforward content needs.

Strapi

The self-hosted, open-source option. You run it yourself (or use their cloud), which means lower ongoing cost but higher operational overhead. Full control over your data — no vendor lock-in.

The content type builder is straightforward, the REST and GraphQL APIs work well, and the plugin ecosystem covers most common needs. For teams with existing infrastructure to manage, this fits naturally.

Best for: Projects that need data sovereignty, teams comfortable with self-hosting, businesses that don't want recurring SaaS costs.

Watch out for: Security updates, database management, and hosting costs are on you. Self-hosted means you maintain it.

When to skip headless entirely

For most small business websites — including marketing sites, service business sites, portfolio sites — a headless CMS adds unnecessary complexity.

If your content changes a few times a month, if only developers or technically-capable people are updating it, and if you're building in Next.js with MDX or similar, you likely don't need a CMS. Git-based content (MDX files in a repository, deployed via Vercel or Netlify) gives you version history, content reviews, and workflow for free — without the API dependency, the subscription cost, or the migration risk.

The better question isn't "which CMS should we use?" It's "do we have a content management problem that a CMS solves, or do we just think we should have one?"

For projects where a CMS genuinely makes sense, we evaluate and implement the right fit based on your team's workflow and technical setup. That's part of our web development work. If you're trying to make this decision, book a call and we can work through what your content operations actually require.