Choosing a headless CMS that suits your editors

Pick a headless CMS by starting with the people who will work in it every day. Then look at hosting, the pricing model and how easily you can leave later. All the well-known systems can deliver content to your frontend through an API. They differ in the editing experience, in who runs the servers and in what the bill looks like three years from now.

First ask whether you need headless at all. A separate frontend with its own CMS gives you freedom, and also one more system to run. Erik covers that question in when headless architecture makes sense.

Start with the editors

Who puts content in, and how often? A marketing team that builds landing pages every week wants something different from a product team that edits a help text now and then.

The questions I ask:

• Do editors want to see a page before it goes live?
• Do they assemble pages from blocks, or fill in fixed fields?
• Are there several languages, and who translates?
• Does someone need to approve content before it is published?

Storyblok includes a visual editor in every plan: an editor clicks a block in the preview and changes it there. In Strapi and Payload, editors mostly work in forms with fields. That is fine for structured content, but a marketer who wants to build pages without a developer will find it clumsy fairly quickly.

During the trial, let a real editor work with real content for a week. You learn more from that than from any vendor demo.

Self-hosted or SaaS

Strapi and Payload are open source and you can host them yourself. Strapi's community edition is MIT licensed, while some enterprise features fall under a separate licence. Strapi runs on PostgreSQL, MySQL, MariaDB and SQLite. Payload is MIT licensed too, and it installs directly into the app folder of an existing Next.js project. Your CMS and your site then share one codebase and one deployment.

Sanity sits in between. You can host the Studio, where editors work, wherever you like, but the content lives in Sanity's Content Lake and APIs, which Sanity hosts. Storyblok is fully SaaS.

Self-hosting means you own updates, backups and security. If you already run servers, that is manageable, but it is work that comes back every month. We wrote down how we weigh that in Vercel or self-hosting.

Price it for year three

A SaaS CMS charges for whatever grows on your side. With Storyblok that means seats, API requests, traffic, locales and the number of spaces. Each of those has a limit per plan, and above it you either pay extra or move to a more expensive plan.

So price it for the situation in year three: more editors, a new market with its own language, more traffic after a campaign. Check which of those grows first for you and what that does to the plan.

Self-hosting still comes with a licence and pricing terms to read. Directus is a good example. Organisations with less than $5 million in annual revenue and fewer than 50 employees get every feature without licence fees, also when they self-host. Larger organisations fall under the paid plans. That is a fair arrangement, but you want to know it before you choose, not when finance asks about it.

Lock-in lives in your content model

Moving to another CMS is rarely impossible, but it is often a lot of work. Most of that work is rich text: many systems store formatted text as their own JSON structure, which you have to convert when you move. On top of that you migrate images and the references between pieces of content.

So test the export before you sign. Use the content from your proof of concept and import the result into another system.

Two rules keep lock-in small:

• Keep business logic out of the CMS. Webhooks and plugins are handy, but logic belongs in your own code.
• Let the frontend fetch content through a thin layer of your own, so a migration changes one place.

Also look at who owns the vendor. Payload became part of Figma in June 2025, and the team said at the time that Payload stays open source and self-hostable. With an MIT licence you have the code either way. With a SaaS vendor, all you have is your export.

The options side by side

There are other good systems, but these five already cover the main choices: self-hosted or SaaS, and forms or a visual editor.

How I would run the selection

1. Write down who works in the CMS and what they do in a typical week.
2. Model three real content types, with their relations and languages.
3. Build a small proof of concept with two candidates against your own frontend. A few days per candidate is enough.
4. Let an editor work in it for a week.
5. Export everything and see whether you can import it elsewhere.
6. Price both for year three.

Then pick the system your editors like working in, as long as the export and the pricing hold up. The frontends and backends we work with are listed on our technology page.

Sources

• Strapi: licence (GitHub)
• Payload on GitHub
• Payload: Payload is joining Figma
• Directus: pricing and Open Innovation Grant
• Sanity: hosting and deployment
• Storyblok: pricing