Headless CMS — who in the company gets to change what, and what it costs

In a proposal, headless sounds like a technical decision you can leave to the contractor.

You cannot. It is a decision about who in your company will be able to change what, and how much every change nobody planned for will cost. Headless is not a better content management system — it is a different division of labour between the editorial team and the developer, and the whole calculation follows from that shift.

This piece settles who that trade pays off for — for the person who signs the contract and lives with its consequences for years.

What headless CMS is — content on one side, appearance on the other

A classic content management system keeps content and the display template in one place: you change text in the panel, the system drops it into the template and serves a finished page. That is how WordPress works.

Headless keeps only the content and serves it through a programming interface — as data, with no appearance attached. The appearance is a separate program that fetches that data and lays it out as a page.

An analogy that is enough to decide with: a classic CMS is a shop with the storefront and the warehouse in one building. Headless is a separate warehouse that has no idea what the storefront looks like — its whole advantage and its whole cost.

What follows:

• The same content feeds many places — a website, an app, a showroom screen, a partner catalogue — since nothing in it recorded what it should look like.
• An editor cannot break the page layout, having no access to it — they fill in fields, not a free-form editor.
• And the reverse: an editor cannot change the layout, even when it needs changing. That's a developer's job.

Headless CMS vs "static CMS" — two different things that travel together

These terms get mixed up constantly, showing up together while meaning different things.

Headless CMS is a warehouse — it holds content and serves it on request. A static site generator (SSG, sometimes "static CMS") is a factory — it takes content from the warehouse and produces finished HTML files before anyone visits.

You can have one without the other: a headless system assembling the page on every visit, or a static generator reading files from a repository with no panel at all. Together, though, they built the setup sold for years as JAMstack — hence the confusion.

For you it comes down to one question: how many minutes after saving a change does a user see it. With a factory, the site has to rebuild; on a large site, that's minutes, not seconds — the same thing that trips up editorial work, covered below.

What actually changes for the person publishing content

This is the section no proposal covers, and it decides whether you'll be happy with the system in two years.

What gets easier. Content is entered into fields — title, lead, price, photo — so it cannot be incomplete or break the layout. The same product description reaches everywhere it's needed with no copying, and language versions become values of one field instead of three separate pages.

What gets harder. There's no drag-and-drop, and no twenty thousand plugins for bolting on a feature without a developer. A new kind of section — not new text, a new way of presenting content — is a developer's job, and goes into a queue, not the panel.

The preview trap — the biggest shock after leaving WordPress

In WordPress an editor writes and sees how it will look. In headless, by default, they see nothing — the panel only has data, and the appearance lives in a separate program.

In a badly implemented setup: an editor clicks "Save", then waits for the site to rebuild to see whether the heading drifted away from the photo. Tens of seconds on a small site, several minutes on a large one — three fixes in one paragraph mean three such cycles, eating hours every week for a team used to an instant preview.

An instant preview can be built — but it has to be built. In practice that means a draft mode on the frontend pulling the unsaved content straight from the panel and rendering it live; in Next.js that's draft mode. Separate engineering work, not a toggle — if it's not in the quote, it's not in the project.

A question worth asking before signing: what does previewing an unsaved change look like, and how many seconds pass between "save" and seeing the effect? "You'll need to refresh after the rebuild" is an answer that costs the editorial team time every day.

WordPress or headless — when a monolith is enough

Honestly: for most company sites, WordPress is enough, and headless is a cost with no return.

The scale of the monolith is hard to overstate. According to W3Techs, 69.1% of sites run on some recognisable CMS, and WordPress alone is 40.7% of all sites and 58.9% of the CMS market (checked at source on 9 September 2026). Not an argument for WordPress — information about how easily you'll find, or switch, a contractor for it.

What that statistic does not say. Technology-detection tools see what shows up in code sent to the browser. Headless hides the backend by definition — the frontend framework is visible, the system serving content is not. So headless's market share cannot be measured the way WordPress's can, and any figure you meet comes from a survey, not a measurement.

The most-quoted one: 73% of respondents already use a headless architecture, and nearly 98% of the rest plan to consider it within the year. Worth knowing who was asked, though. Censuswide, on behalf of WP Engine, July 2024: 1,015 respondents — CTOs, CMOs and IT decision-makers — at companies averaging around 800 million USD in annual revenue, in the US, UK and Australia.

In other words: not a statement about companies your size, commissioned by a vendor selling headless hosting, and self-reported rather than verified. The number is true and not useful for your decision — it describes corporations with technical teams on payroll. We quote it because you'll meet it in proposals as "everyone already does this".

Three situations where headless pays off:

1. The same content goes to more than one place — a website, an app, a screen at a point of sale, a partner catalogue. With one channel, you pay for flexibility nobody uses.
2. You're building the frontend in React or Next.js anyway — headless then completes a competency you already have, rather than adding a new one.
3. Security or performance requirements a plugin-based monolith can't carry — no publicly reachable panel, no plugin layer as an attack surface.

Three where it doesn't: one channel with nothing suggesting a second; an editorial team with no technical backup, since marketing loses the ability to add sections itself; a budget with no line for upkeep, since two systems mean two update cycles and two places to fail.

Choosing a specific tool rather than an architecture is a different decision, covered in our platform comparison; the conceptual layer underneath — what a CMS is and who gets to change what — is unpacked in our article on content management systems. For an online shop the same decision plays out differently, with its own trade-offs.

A middle path: WordPress used as headless

There's a route between the two worth knowing about: often the cheapest option for a company that already has a WordPress site with years of content in it.

WordPress stays as the panel and content warehouse, but stops drawing the page — a separate frontend fetches content through a programming interface. The editorial team keeps working where it always worked, and you gain speed and freedom on appearance.

What you gain: zero content-migration cost, a team that skips learning a new panel, and a real load-time improvement once the frontend stops dragging the theme and plugin layer.

What you lose: most plugins, since they attach to an appearance that no longer exists — forms, galleries and SEO mechanisms need rebuilding on the frontend. The preview problem returns, and you maintain two systems instead of one.

When it makes sense: lots of content, an editorial team attached to the panel, and a problem that's purely performance and appearance. When it doesn't: plugins do half your site's job — then splitting WordPress in two costs more than building fresh.

Two deployment models, not a ranking of tools

The names you'll hear — Contentful, Sanity, Strapi, Payload — split into two models, and that split changes your arithmetic, not the nicer API.

Choosing a specific product within a model is a separate conversation. Here it's enough to know which model you're buying — it decides whether in three years you're discussing a price rise, or finding someone to patch a server.

What headless demands of a company before it gives anything back

You need ongoing technical support — not "someone who knows WordPress", but someone working in TypeScript and React. Every appearance change and every new kind of section is work in code.

That doesn't mean hiring someone. It means that line item needs an owner: your own developer, an agency on retainer, or a contractor with a response time in the contract. The one setup that never works is a system built once by someone who then disappeared — it holds up until the first change that can't be made in the panel, then becomes something everyone's afraid to touch.

So the question isn't "do we have a developer", it's "who maintains this in two years, and what does it cost per month". If there's an answer, headless is in play.

Two systems instead of one means two update cycles, two points of failure, and two things to test after every major change — and can mean the panel and frontend have to be separate deployments, a case we hit with Payload and Next.js's pre-rendering mechanism, covered in our article on Next.js and React.

You're trading one dependency for another

Headless is often sold as "freeing yourself from WordPress". Worth knowing what that dependency gets replaced with.

In a monolith you depend on a tool — known to half the market, so you can swap contractors in a week. In headless you depend on a skill set: a Next.js frontend with its own routing, data model and panel integration won't go to "whoever's available". It goes to a mid-to-senior React developer, and there are fewer of those, at higher cost.

Not an argument against headless — a question to ask before signing: who besides you can maintain what you're building, and what do we get if we part ways?

The bill — where it costs more, and where less

We're not quoting figures for a headless build, since we don't know a study comparing both approaches on the same projects. What can be shown honestly is the mechanism.

In a monolith, changing a section's appearance is often panel work or a small template edit. In headless, the same change usually touches two places — the data structure and the frontend component displaying it — and both have to move together, or a mismatch shows nothing. That's why this isn't about the hourly rate, it's about the number of hours, and why the section types you get at launch matter so much.

A software house's quote and a freelancer's quote for the same brief are rarely pricing the same scope, even naming the same task — the gap describes what's included, not the same work priced differently.

Where headless is cheaper: another channel for content that already exists, plugins you don't buy, security incidents you don't have with no publicly reachable panel. Where it's more expensive: the build, every appearance change, keeping the skill set in-house even when nothing's changing.

What you don't get bundled with headless

You don't buy speed — you buy the possibility of it. Headless renders nothing by itself; the frontend decides whether the page arrives ready or still has to assemble itself. You can build a slower site on headless than on WordPress.

You don't buy visibility in Google. A frontend fetching content only in the browser shows the crawler an empty page — the mechanism is covered where we compare Next.js and React.

You don't buy independence from your contractor — only a different dependency.

And you don't buy a reason for anyone to visit. Architecture decides how content reaches the reader, not whether there's anything worth reaching for. If the system decision comes before that question is answered, it's too early — the answer sits in website strategy, not a technology proposal.

Where these numbers come from

• WordPress and CMS market share — W3Techs, checked at source on 9 September 2026: 69.1% of sites on a recognised CMS, WordPress 40.7% of all sites and 58.9% of the CMS market.
• 73% of firms using headless and 98% planning to evaluate it — a Censuswide study commissioned by WP Engine, July 2024, 1,015 respondents (CTOs, CMOs and IT decision-makers) at companies with average revenue of around 800 million USD, in the US, UK and Australia; checked at source on 11 September 2026. This is a corporate survey commissioned by a vendor — not a market measurement and not a statement about companies your size.
• Why there's no measurement of headless market share — technology-detection tools only see code sent to the browser, and headless hides the backend. That's a limit of the method, not a gap in the data.
• Draft-mode preview on the frontend — Next.js documentation, checked at source on 11 September 2026.
• Software-house-versus-freelancer pricing spread — deliberately given as a mechanism, not a figure: no study comparing them on this market exists that we would stand behind.
• Cost comparison between headless and a monolith on the same projects — we don't know of such a study, which is why no multiplier or range is given here.