Dardo
ENESPT
ENESPT

Headless CMS development: Sanity, Payload, Contentful and more

Headless CMS development is setting up the system your editors publish in and connecting it to a front end that stays fast. Dardo models your content, configures Sanity, Contentful, Payload, Strapi, Storyblok or EmDash, and builds the previews, translations and migrations around how your team publishes. We run our own sites on a headless CMS.

By Dardo editorial team8 min read
Get a proposalMessage us on WhatsApp
Dardo / Editorial illustration
On this page

What headless CMS development includes

A headless CMS stores and edits content without drawing the website: the site, an app or an AI agent fetches the same entries through an API. We set up the content system and its connection to your front end, not an install with default fields.

  • A content model: types, fields, references and validation, documented for editors and developers
  • CMS configuration: roles, required fields, publishing rules and scheduled publishing where the plan has it
  • Draft previews that show unpublished entries in the site's real design
  • Language setup: translated fields or one entry per language, each with its own slug
  • Migration of existing content and media, with alt text and a redirect map
  • Front-end integration in Astro or Next.js, with a rebuild or cache refresh on publish
  • A handover session and a short guide for the people who publish

When is a headless CMS the wrong choice?

A headless CMS is the wrong choice when it adds a second system without solving a problem you have. If a small team publishes comfortably in WordPress and relies on its plugins, keeping WordPress is usually cheaper; our comparison of WordPress and custom websites sets out when. If marketers want to compose new layouts visually, Webflow development fits better than structured fields.

Headless pays off when the same content feeds several sites or apps, runs in several languages, must be served as static HTML, or holds structured facts, such as prices, FAQs and sources, that many pages reuse.

How do Sanity, Contentful, Payload, Strapi, Storyblok and EmDash compare?

The differences that matter most are where the content is stored, how far the free tier goes and what the first paid plan costs. Figures are from each vendor's pricing page or announcement as of October 2026; plans change often, so check them before you sign.

How do Sanity, Contentful, Payload, Strapi, Storyblok and EmDash compare?
CMSWhere content livesFree tierFirst paid stepKnow before choosing
SanitySanity's hosted databaseUp to 20 seats, 2 public datasets, 2 rolesGrowth, USD 15 per seat a monthThe Free plan has no separate Editor role
ContentfulContentful's cloud10 users, 2 roles, 100,000 API calls a month, 10,000 recordsLite, USD 300 a monthA large jump from free to paid; part of Salesforce since 1 September 2026
PayloadYour own server and databaseOpen source under MIT, no license feeNone required; you pay for hostingInstalls inside a Next.js app; its team joined Figma in June 2025
StrapiYour own server (Community edition)Open source under MIT, no license feeGrowth, USD 45 a month with 3 seatsLive Preview, Releases and Content History are paid features
StoryblokStoryblok's cloud1 seat (2 at most), 100,000 API requests a monthGrowth, USD 99 a month with 5 seatsIts free Starter plan is sold for testing and personal projects
EmDashYour own Cloudflare account or a Node.js serverOpen source under MIT, no license feeNone required; you pay for hostingStable 1.0 only since 28 September 2026; what we run our own sites on

Ownership is moving too. Salesforce completed its acquisition of Contentful on 1 September 2026, and Payload's team joined Figma in June 2025; Figma says Payload will remain open source. Neither change breaks a working site, but both belong in a risk review. We aren't a certified partner of any of these vendors.

Why the content model matters more than the CMS

The content model shapes daily editing more than the brand of CMS. Before configuring anything, we list every page type and repeated block, decide which are fixed layouts and which are entries, which fields are required and what links to what. Entries link by reference, not pasted URLs, so menus and related links follow a page when it's renamed or moved.

In the CMS behind dardo.studio, each service page has a title, a short menu title, a summary, an SEO title and description, FAQs, sources and the date its facts were last reviewed. The CMS refuses to publish an entry that lacks a meta description of at most 160 characters, a cover image or alt text on every image, and the same checks apply to drafts an AI agent writes through its MCP server.

How do previews and publishing work on a static site?

Editors should see a draft in the site's real design before it goes live, without a developer deploying anything. On dardo.studio, the CMS's Preview button opens a preview page with a signed, short-lived token. It's the only page rendered on request, never cached or indexed; every public page is built ahead as static HTML.

Publishing triggers a rebuild, and the change is live a few minutes later: the price of fast, cheap static pages. Content that must change by the minute, such as stock or prices, is better rendered on request with short caching. Our Astro development and Next.js development pages explain when each approach fits.

How should translations be set up in a headless CMS?

Plan languages in the content model from the start, because adding them later touches every content type. A single entry with a translated value per field suits pages built the same way in every language; one entry per language, with its own slug and publish state, suits markets that need different copy and URLs. Our own site uses the second pattern for English, Spanish and Portuguese, and the CMS flags each translation whose English source has changed since.

Check locale limits before choosing a plan. As of October 2026, Contentful includes 2 locales on Free and 3 on Lite; Storyblok includes 2 on Starter and Growth, with extra locales on Growth at USD 20 a month each; Sanity lists unlimited locales on every plan. Market research, hreflang and copy for each language belong to our multilingual websites service.

Moving from WordPress to a headless CMS

A WordPress migration is mostly content mapping: posts, pages, custom fields and media become typed entries, and every old URL gets a destination. We inventory the site, map each post type and custom field to a content type and convert page bodies to structured rich text, flagging shortcodes and page-builder markup that need an editor's decision.

Redirects, metadata and search checks follow our website migration process, and our guide to moving from WordPress to Astro covers the front end. When only the editing experience hurts, a headless move can keep every URL as it is.

What does headless CMS work cost, and who owns it?

The price follows the content model and the number of moving parts, not the CMS you pick. These factors move it most:

  • Content types and reusable blocks to model, and how strict their validation is
  • Roles, approval steps and scheduled publishing
  • Languages, and how translations are produced and reviewed
  • Volume and condition of the content to migrate
  • Integrations such as site search, commerce, a CRM or AI agents

Vendor subscriptions are billed to your company directly and listed apart from our fee. Self-hosted options trade the subscription for hosting and upkeep; on our own CMS we record a database restore point before every schema change or upgrade. You own the CMS account, API keys, schema and content, and we test a full export before launch. Ongoing care fits a website maintenance plan.

Questions before you choose

Which headless CMS do you recommend?

It depends on who hosts it and who edits in it. Sanity, Contentful and Storyblok are hosted for you and bill by seats, locales or usage. Payload, Strapi and EmDash have no license fee but run on infrastructure you pay for and maintain. We recommend one after a short discovery of your editors, languages, content volume and hosting.

Can you work with the headless CMS we already have?

Yes. If you already run Sanity, Contentful, Storyblok, Strapi or Payload, we start by auditing the content model, roles and preview setup, and fix what slows editors down in place. Changing CMS is only worth it when the current one blocks something specific, such as languages, cost or a hosting requirement.

Can our marketing team build pages without a developer?

Within the blocks we design, yes: editors add, reorder and fill sections such as heroes, cards, FAQs and calls to action, and check them in a preview first. A new kind of block or layout needs development. If your team wants to design new layouts freely, a visual builder such as Webflow or Framer is the better fit, and we'll say so.

Is a headless CMS better for SEO?

Not by itself: rankings depend on content, links and competition. What headless allows is a front end that serves fast HTML with full control over titles, descriptions, structured data and redirects. Our own CMS won't publish a page without a meta description and image alt text, and it generates the sitemap, redirects and structured data from the entries.

What happens to our content if we change CMS later?

Your content stays exportable through the vendor's API, but each CMS stores rich text and references in its own format, so a move means converting them. We document the content model, keep the schema in your repository and test a full export before launch, so leaving is a planned project rather than a rescue.

How long does a headless CMS project take?

It depends on the number of content types, the languages and the content to migrate, so the schedule goes in the proposal rather than a standard number. Modelling and previews come first, migration runs alongside the front-end build, and editors test on real entries before launch, not after it.

From the blog

Sources & further reading

Sources behind this page, with further detail from the original publishers.

From your content to a CMS editors use

Send what you publish, in which languages and where it lives today. We reply with the questions that shape the model, a first CMS recommendation and how the work would be scoped.