Headless CMS gets sold as a mandatory step into "modern architecture". It is actually a trade: you get a fast front end and a proper API, and you pay for it with a second service in your infrastructure, harder previews and a steeper learning curve for editors. Below is how it works technically, the cases where it genuinely pays for itself, when it becomes needless complexity, and how the popular options differ on cost of ownership rather than on their marketing pages.

What headless means and how it differs from a traditional CMS

A classic CMS is three things in one box: a content store, an admin interface, and templates that turn content into HTML. Headless removes the third part. What remains is storage plus an editor, exposing content outward as structured JSON over an API. What happens next is the front end’s business — build the site with Next.js, feed the same text into a mobile app, or push it to a screen in a showroom.

1. 1

   The editor publishes an item

   They see fields rather than a page: title, summary, gallery, price, tags. The fields are defined by a schema, so breaking the layout is structurally impossible — there is no layout in here to break.

2. 2

   Content becomes available over an API

   The CMS returns structured data via REST or GraphQL. The same record is simultaneously available to the website, an app, a newsletter and any external system that speaks HTTP.

3. 3

   The front end fetches and builds pages

   Either at build time or on first request with caching afterwards. This is the pivotal detail: the visitor receives finished HTML rather than the result of a live database query.

4. 4

   A CDN serves the result

   The page sits at the network edge, close to the user. Hence the typical 100–300 ms response with no caching plugin involved — there is nothing left to cache, it is already static.

// One record — reused by the site, the app and the newsletter.
// revalidate keeps the page static but never older than an hour.
const post = await fetch(
  `${CMS_URL}/api/posts?slug=${slug}&locale=${locale}`,
  { next: { revalidate: 3600 } },
).then((r) => r.json());

What a business actually gets out of it

• Speed without a fight. Pages ship as static files, so Core Web Vitals land in the green by default rather than after three rounds of plugin tuning.
• One content set, many channels. The catalogue you maintain in the CMS feeds the site, the app, a marketplace feed and a partner import — no manual copying and no price drift between them.
• Redesign without moving content. The front end can be rewritten from scratch without touching the data. That typically saves 30–50% of the next redesign budget, because content and structure stay where they are.
• A smaller attack surface. No public admin panel at a well-known URL and no plugins with write access to site files. The CMS lives on its own domain behind authentication.
• Localisation that works. Locale is a field in the schema, not a third plugin stacked on two others. What to do with that is covered in our guide to multilingual websites.

When headless is needless complexity

This is the part nobody writes down. The approach has a real price, and most often it gets paid by projects that do not need it. Here are the signals that make us talk a client out of headless.

The most painful item is preview. In a traditional CMS the editor clicks "Preview" and sees the page. In a headless setup preview has to be implemented on the front end, and done carelessly it turns editorial work into guesswork. Budget 8–16 hours of development for it upfront, otherwise "put it back the way it was" arrives within a month. The broader cost comparison sits in our write-up on Next.js versus WordPress.

The options that actually reach production

A practical selection rule: if nobody on your side owns servers, take a hosted product and put the subscription in the budget. If data residency matters or you already pay for a VPS, self-hosted is cheaper over time but moves patching and backups onto you. Those hours are a real cost too, and the honest place to count them is inside an annual maintenance budget.

What it costs and how to make the call

Upfront, headless runs roughly 20–35% above an equivalent site on a traditional CMS. The difference goes into defining content schemas, wiring preview, running a separate environment for the CMS and connecting the two halves. After launch the maths reverses: the next redesign costs less, adding a channel costs almost nothing, and monthly plugin fees disappear.

1. 1Count your channels. One means a traditional CMS. Two or more, or an app planned within the year, justifies headless.
2. 2Count publishing frequency. Under ten updates a month you will not feel the difference; past a hundred, structured fields save editors real hours.
3. 3Check who maintains the site. Without a standing developer, a self-hosted headless stack becomes an abandoned service within six months.
4. 4Put preview and access roles into the quote, not into "we will add it later". Later costs twice as much.
5. 5Write the content export format into the contract. Portability is the whole point of the approach, so it should be stated rather than assumed.

Frequently asked questions about headless CMS

In short

• Headless splits the content store from the front end: content is served as structured JSON, and pages are built in advance and delivered from a CDN.
• It pays off under two conditions — content goes to more than one channel, or publishing volume is high enough that structured fields save editorial time.
• Expect a 20–35% premium at build time, offset later by cheaper redesigns and near-free channel additions.
• Preview, access roles and a content export format belong in the original quote. Those three omissions are why projects migrate back to a traditional CMS.