"Headless" now appears on almost every architecture slide. What rarely appears is what you take on permanently in return. This article answers the question against four criteria you can count in your own organisation.
The short answer: A headless CMS pays off when three conditions apply at the same time: you publish the same content across several serious output channels, your presentation requirements exceed what your template system offers, and you have permanent front-end development capacity, either in-house or secured by contract. If one of the three is missing, a traditional or hybrid system is almost always the faster and cheaper choice.
Two terms first, because they regularly get mixed up in these conversations. A CMS (content management system) is the software your editorial team uses to maintain content; in the traditional setup it stores the content and builds the finished page from it. "Headless" means the second part is absent: the system manages content and hands it out through an API (application programming interface). Turning that into a page, an app or a screen in a showroom is your job. So you are not buying an additional capability, you are giving one up, and taking on the responsibility of operating it yourself for years.
Why traditional does not mean outdated
The most widespread misconception is that a traditional system cannot hand out content in machine-readable form. That was true once and has been wrong for years.
Drupal, one of the systems we work with, has shipped JSON:API as a stable core module since version 8.7 of 1 May 2019, and it has remained part of core up to today's version 11. Any standard installation can serve content through a clean interface and render its own pages at the same time. If you need an interface to feed an app or a dealer portal, you do not have to decouple anything for it. The most common error of reasoning in this discussion, "we need an interface, therefore we need headless", is settled by that.
The supposed either-or question breaks down into three options:
- Traditional (coupled): one system, one front end. The "front end" is the layer your visitors see, the "back end" the administrative layer behind it.
- Hybrid (partly decoupled): the CMS continues to serve the website itself and additionally provides content through the interface for other channels or for individual, purpose-built components.
- Fully decoupled (headless): the CMS renders nothing at all. Every interface is a development project of its own.
In our experience from Swiss projects, the middle path is the most common one and the most poorly represented in the debate.
The four questions the decision hangs on
1. How many output channels do you actually serve?
Count only channels that need the same content and that exist today or for which a funded project exists: website, app, online shop, dealer portal, in-store screen, print catalogue drawn from the same source.
Our rule of thumb: from the third real channel onwards, separation starts to pay for itself, because otherwise you organise the same content maintenance several times over. With one or two channels you are paying for flexibility you never call on. A planned channel without a budget does not count, and that is the most common arithmetic error on this line.
2. How often does your content change, and who changes it?
Count the publications of the past three months and the number of people who actually worked in the system during that time.
Two editors making two changes a month barely notice an awkward preview. Twelve people building campaign pages every week notice it daily, and a loss of convenience turns into a productivity problem. This criterion is the one most often left out of architecture discussions, because the person who will later operate the system eight hours a day is rarely at the table.
3. How much presentation freedom do you actually need?
Not how much would be desirable, but: which specific requirement fails against your template system today?
If you cannot answer that question with an example that has been stuck for months, you do not need the freedom. If you can name three examples, that is a serious argument, independently of the number of channels.
4. Who will look after your front end in three years?
This is the decisive question. A self-built front end is not a project that ends, it is a system somebody has to maintain: updating dependencies, closing security gaps, keeping up with browser changes.
In Switzerland, that exact capacity is the scarcest resource. ICT-Berufsbildung Schweiz puts the additional demand up to 2033 at 128,600 ICT specialists, of whom 54,400 will have to be newly trained. A front end you cannot staff in 2029 is not progress, it is an operational risk.
For a mid-sized company without its own development team, that means the question is not whether you can afford to build it, but whether you can secure its operation through a binding maintenance contract. If you cannot, the answer has already been given.
What you build and maintain yourself in a headless setup
This part rarely appears in vendor material. Dries Buytaert, the founder of the Drupal project, noted back in 2016 that giving up the built-in "layout and display management, user interface localization, and more" means "losing that functionality can be costly, increase your dependence on a developer team, and hinder the end-to-end content assembly experience your marketing team expects, among other things".
That statement is ten years old, and development has not stood still since. Drupal Canvas, carried under the working title "Experience Builder" until September 2026 and available as a stable release since 8 September 2026, addresses precisely this gap: according to the project description, content is to be managed from a single system "across headless and coupled contexts" and pages composed "without relying on developers". How well that holds up in production cannot be judged from the outside. The trade-off becomes smaller, it is not removed.
In concrete terms, the following shifts onto your development budget:
- The preview. Seeing how an article will look before it goes live.
- In-context editing. Changing a text where it stands, rather than in a form field beside it.
- Page composition. Arranging components without tying up development resources.
- Multilingual publishing. Drupal core ships four modules for this. A company publishing in German, French and English maintains three parallel language versions including a translation status per field.
- The small print. Redirects after a relaunch (a new edition with changed addresses), forms with validation, the sitemap as a machine-readable index of pages for search engines, site search, access rights per section.
Modern headless systems have caught up here. Storyblok, which we also work with, offers a visual editor with a live preview. That is not, however, a feature you simply switch on: according to the official documentation it requires a configured preview address, an embedded connection script and correspondingly marked-up components in the front-end code. So the preview has not disappeared, it has become a development task. If it is not carried over during the next front-end rebuild, your editorial team loses it.
The middle path many overlook
The most workable answer is often this: do not decouple the whole website, decouple the one component that needs it.
An example from our portfolio: for Stromer we built the website on Drupal. The bike configurator, by contrast, was created as a standalone web application.
Our reading of that split: the editorial pages keep the convenience of the traditional system, and development capacity flows to where it makes a visible difference. That is exactly what "hybrid" means. How such a web and commerce platform connects to your existing systems is ultimately a question of systems integration, not of CMS choice.
When a headless CMS is clearly the right choice
- Several brands or markets from one editorial team. If the same product content ends up in five country sites and an app, you save maintenance effort from day one.
- An existing front-end team. If your developers already run a front end based on React or Vue (widely used toolkits for purpose-built interfaces), a traditional template system is a brake.
- An interface that is not a website. Product configurators, self-service screens, in-vehicle displays, product data in marketplaces.
- Separate release cycles. If your front end ships weekly but your back end quarterly, the two are already blocking each other today.
One Swiss addition that rarely comes up in architecture discussions and regularly comes up in procurement: where does the content sit? With hosted headless services, the provider decides that. Storyblok names Europe, the USA, Canada and Australia as hosting regions in its official FAQ, with the choice of region reserved for the Premium and Elite plans. A Swiss region is not on that list. Whether that is permissible for your content belongs before the architecture decision, not after it.
The decision grid: eight questions
Work through the list and count the yes answers.
- Do you serve three or more channels with the same content today?
- Does each of those channels already have a budget or an operating team, not just an intention?
- Can you name three specific presentation requirements your current template system cannot deliver?
- Do you have a front-end development team, either in-house or secured through an ongoing maintenance contract?
- Is its capacity committed for 2029 as well, not only for the project phase?
- Are your front end and back end blocking each other today through different release cycles?
- Is your editorial team prepared to give up the preview in its current form, or to have it rebuilt?
- Is it settled which country your content may sit in going forward?
Six or more yes: headless is a viable option. Examine it seriously.
Three to five yes: the hybrid route probably suits you better. Settle the no answers first, before you talk about systems.
Two or fewer yes: stay with the traditional system. You would be trading convenience for a freedom you never call on.
Questions 4 and 5 weigh more heavily than all the others combined: if you hesitate there, no system selection will move you forward.
Conclusion
What you face in the end is a front-end decision, not a CMS decision. You gain presentation freedom and channel independence, and in return you take on the permanent construction and operation of your output layer. That pays off when you carry that responsibility anyway, or deliberately want to carry it.
So examine the four criteria first, that is number of channels, change frequency and editorial team size, specific presentation requirements, and secured development capacity, and only then look at systems. And factor in the middle path: since Drupal 8.7, traditional systems have additionally served content through an interface without requiring you to give up your output layer. For many mid-sized Swiss companies, that is the fitting answer.
Frequently asked questions about headless CMS
What is the difference between headless and hybrid?
A fully decoupled system no longer renders pages. A hybrid system continues to serve the website itself and additionally provides content through an interface for other channels.
Do you need a headless CMS in order to have an interface?
No. Drupal has included JSON:API as a stable core module since version 8.7 of 1 May 2019 and can serve content through an interface while continuing to render the website itself.
From how many channels onwards does headless pay off?
By our rule of thumb, from the third channel that needs the same content and for which budget and operation are already in place. Planned channels without funding do not count.
What does the editorial team lose when moving to headless?
Above all layout and display management, in-context editing and parts of interface localisation. Modern headless systems offer replacements, but these have to be implemented and maintained in the front end. Since September 2026, Drupal Canvas has pursued the approach of closing this gap for decoupled setups as well; how far that carries in practice depends on the project.
What role does the skills shortage play?
A large one. ICT-Berufsbildung Schweiz puts the additional demand up to 2033 at 128,600 ICT specialists, of whom 54,400 are to be newly trained. Anyone running their own front end needs that capacity permanently, not only during the project.
Where does the content sit with a hosted headless CMS?
The provider determines that. Storyblok names Europe, the USA, Canada and Australia as hosting regions, with the choice of region reserved for the Premium and Elite plans. Settle this point before the architecture decision.
Facing a CMS decision?
Arcmedia has been supporting companies with digital commerce projects since 1995, from analysis through implementation to ongoing operations. Our experts are happy to advise you on your project.
Always up to date with the latest trends and tips: subscribe to our newsletter.
Sources
- Drupal.org, "Drupal 8.7.0 is available", 1 May 2019, evidence for the date since which JSON:API has been in core
- Drupal.org, "JSON:API lands in Drupal core", Dries Buytaert, 21 March 2019
- Drupal.org, JSON:API module documentation, evidence that the module is part of core up to Drupal 11, accessed 10 September 2026
- Drupal.org, "How should you decouple Drupal?", Dries Buytaert, 22 March 2016, a 2016 position and explicitly placed as such in the text
- Drupal.org, project page Drupal Canvas (formerly "Experience Builder"), stable release 1.11.0 of 8 September 2026, accessed 10 September 2026
- Drupal.org, Multilingual Guide, "Choosing and installing multilingual modules"
- ICT-Berufsbildung Schweiz, demand forecast 2033, prepared by BSS Volkswirtschaftliche Beratung AG, 18 September 2025
- Storyblok, official FAQ "Where are your servers (or AWS sites) located?"
- Storyblok, official documentation "Visual Editor"
- Arcmedia, project page Stromer and technology pages Drupal and Storyblok
