Headless Architecture: When Splitting the Frontend Is Worth It

A headless solution stores content in a backend that has no frontend of its own, and serves it over an API to whatever wants to display it: a website, a mobile app, a kiosk, a set of digital signs.

That separation is genuinely valuable in specific situations and genuinely expensive in all of them. The useful question is not whether headless is better, because it is an architecture rather than an upgrade. The question is whether you have the problem it solves, and most sites do not.

Table of contents

• What headless actually means
• The cases where it earns its keep
• What it actually costs
• Rendering, which is the real decision
• When to skip it
• What it looks like to run
• How this fits the rest of the stack
• FAQ

What headless actually means

A traditional content management system owns the whole pipeline. Content goes into a database, templates render it, and the same application serves the HTML. The editing interface and the public site are two views of one system.

A headless system keeps the repository and the editing interface and removes the rendering. Content is exposed over a REST or GraphQL API, and something else decides how to present it. The head, meaning the presentation layer, is detached. Hence the name.

It is worth distinguishing this from decoupled, which people use interchangeably and should not. In a decoupled setup the CMS still renders and pushes artifacts to a frontend. In a headless one the frontend pulls content and does all the rendering itself. The difference determines who owns the build and who owns the cache.

None of this is new. Separating a content store from a presentation layer is how large publishers have worked for decades. What changed is that the tooling got good enough for smaller teams to consider it.

The cases where it earns its keep

Four situations where the split pays for itself.

• Genuinely multiple frontends. A website, a native app and an in-store display all reading the same content. This is the original case and still the strongest one. Maintaining the same content in three systems is worse than any API.
• The frontend team wants to move independently. If your site is a React or Next.js application and the content people are blocked on frontend deploys, or the reverse, the split removes a real bottleneck.
• Content outlives the presentation. Organisations that redesign every few years benefit from content that is not entangled with a theme. A redesign becomes a new frontend against the same API rather than a migration.
• Composability. When content is one of several services assembled at the edge, alongside search, commerce and personalisation, a CMS that insists on owning the page is in the way.

Notice what is not in that list: speed. A headless site is not automatically faster. A well-cached traditional CMS and a badly built headless frontend that makes six API calls per page render are not close, and the second one is the headless one.

What it actually costs

The parts of the bill people underestimate.

You now own the frontend completely. Every page template, every route, every form, every preview, every error state. The CMS gives you JSON. Everything a visitor sees is code somebody on your team writes and maintains.

Preview becomes a project. In a traditional CMS, an editor clicks preview and sees the page, because the CMS renders it. Headless preview means a draft-aware API, a preview mode in the frontend, and a build or a server-rendered path that honours it. This is consistently the feature teams forget to budget for and the one editors complain about first.

Editors lose the visual relationship to the page. They are editing fields in a form, not a page they can see. Good headless products mitigate this. None of them eliminate it, and it is a real reduction in editor autonomy that shows up as more requests to the development team, not fewer.

And the operational surface grows. You now have a content API, a frontend application, a build pipeline, and a cache layer between them, each of which can fail independently. When a page is wrong, the first question is which of the four is responsible.

Rendering, which is the real decision

Once content is behind an API, you have to decide when it turns into HTML. This choice affects performance and cost far more than the CMS you pick.

1. Static generation. Build every page at deploy time. Fastest possible delivery, cheapest hosting, and a full rebuild on every content change. Excellent up to a few thousand pages, painful beyond that.
2. Incremental regeneration. Build most pages, regenerate individual ones on demand or on a schedule. Keeps static delivery without the full rebuild. This is where most content sites should land.
3. Server-side rendering. Render per request. Always current, needs a running server, and every page view costs an API call unless you cache it properly.
4. Client-side fetching. Ship a shell and fetch content in the browser. Worst option for content pages: search engines and users both wait, and the content is not in the initial HTML.

The default should be incremental regeneration for content sites and server rendering only for genuinely personalised pages. Client-side fetching for primary content is a decision to be slower and less indexable in exchange for a simpler build, which is almost never the trade you want on a site whose purpose is to be read.

When to skip it

A short and honest list of cases where headless is the wrong call.

• One website, one team, content that changes weekly. A traditional CMS does this better and with fewer people.
• Non-technical editors who need to manage layout, not just content. Headless gives them fields. If they need to arrange a page, you are about to build them a page builder, which is a product.
• No frontend developer on the team. A headless setup without someone maintaining the frontend is a content API with nothing on the end of it.
• A small marketing site where the real requirement is that it loads fast and someone can edit the copy. Managed WordPress or a static site generator solves this in an afternoon.

Headless is an architecture for organisations with a specific structural problem: multiple surfaces, multiple teams, or content with a longer lifespan than its presentation. Adopting it without one of those means paying the full cost for none of the benefit.

It is fine to start coupled and split later. Content in a well-structured traditional CMS can be exported to a headless one. The reverse, adding editing convenience back to a headless setup, means building it.

What it looks like to run

Whichever way you go, the deployed shape is a small number of pieces.

A headless setup is typically a content API, a frontend application built from a repository, and a cache in front. If you self-host the CMS, add a database and a running service for it. If you use a hosted one, that is a monthly subscription and an API you do not control the latency of.

A coupled setup is one application and one database, which is fewer things to deploy, fewer things to monitor and fewer places for a page to go wrong.

On RunxBuild both shapes fit the same path. A static or incrementally built frontend deploys from a repository with custom domains, headers and redirects, and 120GB of bandwidth included. A self-hosted CMS runs as a service with a managed MySQL or Postgres beside it on the private network. Managed WordPress, if the coupled answer turns out to be the right one, starts at three dollars a month with a file manager and a database browser in the dashboard instead of SFTP and phpMyAdmin.

How this fits the rest of the stack

The thing that makes this decision hard is that the architecture diagram looks similar either way while the running cost does not: a headless setup is usually a frontend, a content API, and a database rather than one application. Pricing both shapes before committing is a twenty minute exercise, and the RunxBuild hosting calculator shows the service, the database, the storage and the bandwidth as separate lines, which makes the comparison concrete rather than architectural.

Useful related references:

• Headless Ecommerce: The Architecture, and the Bill Attached to It
• The Best CMS for Hugo: Git-Based, Headless, or Neither
• PDF Generator API: Buy, Build, or Run Headless Chrome Yourself
• Services on RunxBuild

FAQ

What is a headless solution?

A backend that stores and manages content but does not render it, exposing everything over a REST or GraphQL API instead. A separate frontend application consumes that API and decides how the content is displayed, which is why the presentation layer is described as detached.

Is a headless CMS faster than a traditional one?

Not inherently. Speed comes from how pages are rendered and cached, not from where the content lives. A statically generated headless site is very fast, and a headless site that makes several API calls per page render in the browser is slower than a well-cached traditional CMS.

What is the difference between decoupled and headless?

In a decoupled setup the CMS still renders content and pushes it to the frontend. In a headless setup the CMS renders nothing and the frontend pulls content over an API and renders it itself. Headless is a stricter form of the same separation.

What do you lose by going headless?

Rendering, preview and editor context. You own every template and route, preview becomes a feature you build rather than one you get, and editors work in forms rather than on a page they can see. You also gain several independently failing components between content and visitor.

When should I not use a headless CMS?

When you have one website, one team, and editors who need to manage layout rather than just fields. If nobody is maintaining a frontend application, a headless CMS is a content API with nothing consuming it, and a traditional CMS or a static site generator will do the job with far less to run.