A headless setup does not reduce the maintenance burden. It splits it in two and makes the boundary between the halves the most important thing in the contract. Organisations that decouple without redrawing the support model end up with two suppliers who each believe the other owns the problem.
The architecture is often the right choice. The support arrangement around it is where the money and the downtime go.
A headless content management system stores and manages content, and delivers it through an interface rather than rendering pages itself. Editors work in a familiar back end. A separate application, built and deployed independently, fetches the content and produces what the visitor sees.
The word headless refers to the missing front end. A traditional system holds content and templates together and serves finished pages. A headless one holds content and hands it over.
Decoupled is the more accurate word for most real implementations, because the two halves are usually built and run by the same organisation rather than being genuinely independent products.
A traditional CMS renders the pages a visitor sees. A headless CMS does not, and something else has to.
That single difference produces the rest. A traditional system is one application, one deployment, one place where a change goes live and one supplier who can fix it. A decoupled system is two applications with two deployment pipelines, a contract between them that both must honour, and a build step between an editor pressing publish and a visitor seeing the change.
The advantages are real. Content can serve a website, an app and a partner integration from one place. The front end can be rebuilt without touching the content model. Pages can be delivered as static files, which is fast and hard to attack.
The costs are equally real and less often quantified. More infrastructure, more build tooling, more places for a change to fail, and a preview experience that has to be engineered rather than being a feature of the box. Editors who could previously see their change immediately now wait for a build, unless somebody has paid for the work that makes preview instant.
Choose it for a reason you can name. Multiple channels consuming the same content is a reason. Performance targets a well-tuned traditional stack cannot meet is a reason. A preference for the current architecture in a market where headless has been the fashionable answer for several years is not.
Four things, all of which need writing into the support agreement rather than discovered during an incident.
The number of things to patch roughly doubles. Two runtimes, two dependency trees, two sets of security updates, on their own release cadences. The front end typically carries the larger dependency count and the faster-moving one.
Publishing becomes a deployment. On a traditional site an editor’s change is live when they save it. On a decoupled site with static generation it is live when the build completes and deploys, which introduces a delay, a failure mode and a queue. A build that fails at four o’clock on a Friday is a content emergency in a way that a save has never been.
The failure surface changes shape. The content system can be perfectly healthy while the site shows stale content, because the build is failing silently. Monitoring that checks whether the site responds will report everything as fine. Monitoring has to check whether content is current, which is a different test that most estates do not run.
And upgrades become coordinated projects. A major version upgrade on the content system may change the interface the front end depends on, so the two halves have to move together. Our guide to end of life software and what it means for your website covers the published dates that force this, and a decoupled estate has two sets of them.
The boundary is the interface between the two halves, and it is the single most valuable thing to define before signing anything.
Three areas produce almost every dispute. The content model, because a change made by the content team can break the front end without anyone touching the front end’s code. The build pipeline, which belongs to neither half naturally and is usually assumed by both to be the other’s. And performance, because a slow page can be caused by the content system, the build, the hosting or the front end code, and each supplier can honestly say it is not them.
Where one supplier holds both halves, this is a documentation question. Where two suppliers share the estate, it is a contractual one, and it needs a named owner for the interface itself, a joint change process for the content model, and a rule for who leads on an incident before the cause is known. That last one matters most. Without it the first hour of every serious incident is spent establishing whose incident it is.
We have set the boundary out as a responsibility matrix covering both halves and the seams between them, which is worth completing jointly with your suppliers rather than issuing to them.
It is more work to maintain and not harder to maintain well. The skills are ordinary and the volume is higher.
The honest comparison is that a decoupled estate costs more to support than an equivalent traditional one, because there is more of it, and it costs considerably more when the support model has not been redrawn to match the architecture. A single supplier running a well-documented decoupled estate is a manageable arrangement. Two suppliers with an undefined boundary is the expensive version, and the cost arrives as elapsed time during incidents rather than as a line on an invoice.
Content management platforms increasingly support both modes, so this is rarely a choice between products any more. Drupal, for instance, can serve rendered pages and can also act as a content source for a separate front end, which means the decision is about architecture rather than about migrating to a different system.
We build and support both, and we will say when the traditional route is the better answer for a given estate. A decoupled build is a reasonable recommendation when there is a second channel to serve or a performance requirement that needs it. It is a poor one when the only driver is that the current site feels dated, because that is a design problem and decoupling does not solve design problems.
Three clauses cover most of the risk.
Define the interface as a deliverable, with a named owner, a versioning approach and a change process that both halves have to follow. Define an incident lead who takes the first hour regardless of eventual cause, so triage is not a negotiation. And require content-currency monitoring rather than uptime monitoring alone, because on a decoupled estate the site being up says nothing about the site being right.
A decoupled estate needs the same four workstreams as any other, set out in what a website maintenance service should cover, with the boundary drawn through every one of them.
If you are considering a decoupled build, write down the channel or the requirement that justifies it in one sentence. If the sentence needs a second clause to be convincing, the case is not there yet.
If you already run one, check two things this week. Whether anything monitors content currency rather than availability. And whether a single named person owns the interface between the two halves. Both are usually absent, and both are cheap to fix compared with the incident that finds them.
If you want a view on whether decoupling suits a particular estate, we will give you an honest one, including the times when the answer is no.
It changes the exposure rather than reducing it. A statically generated front end with no live connection to the content system removes a large class of attacks against the public site, which is a genuine gain. The content system still exists, still holds the data and still needs securing, and the build pipeline is a new target with access to both halves.
No, and one supplier holding both halves is simpler to run. Two suppliers is a reasonable arrangement where genuinely different skills are needed or where the organisation wants to avoid single-supplier dependency, provided the interface has a named owner and the incident lead is agreed in advance.
Usually yes. The common route is to decouple one section or one channel first, leaving the rest rendered by the content system, which limits the work and produces real evidence about the cost of running both. It also means the decision to continue is made with numbers rather than with a projection.