Headless Architecture

Every website and every app essentially consists of two parts. One part manages the content: texts, prices, images, user accounts. The other part displays this content, i.e. what you see on the screen. Classic systems bind both parts firmly together. A headless architecture separates them: the displaying part, called the “head”, is decoupled. What remains is a system that only provides content, without itself determining how it looks.

One piece of content, many screens

The reason for this separation is the number of devices. Twenty years ago, there was the website, and that was it. Today, a company reaches its customers via the website, a mobile app, a smartwatch, in-store sales displays, and voice assistants. A hard-wired system would have to be rebuilt for each of these channels. That costs time and leads to prices or texts becoming outdated in one place.

With a headless architecture, the editorial team maintains a text exactly once. All channels fetch the same content and display it in their own way. If a product’s price changes, it changes everywhere at the same time. This property is called omnichannel: one data pool, many delivery paths.

On top of that, there is a practical advantage for development. The team responsible for the display and the team responsible for the data can work independently of each other. A website can be completely redesigned without touching the underlying data management. Large online retailers use exactly this to rebuild their interface faster than the competition.

The interface as the connecting link

The connection between the two halves runs via an API. This is a defined interface through which one program can ask another for data. You can think of it as an order counter. The app asks: “Give me product 4711”. The system responds with the raw data: name, price, image address, description text.

What matters is what is not included in this response. It contains no font size, no color, no layout. The response is structured text, usually in JSON format, which is easily readable by machines. How a page is built from this is decided solely by the requesting channel. The mobile app builds a narrow view from it, the website a wide one.

This separation also has downsides that are often overlooked. A classic system comes with a ready-made page including a preview function. With headless, this display layer must first be built, which is additional work. For a small club website, the effort is not worth it. Another common misconception is that headless is automatically faster. Load time depends on how well the interface and the caches are built.

From online shops to AI systems

The term is most commonly encountered in content management systems and in retail. A headless CMS manages articles and images of a news site but only delivers them as data. Headless commerce does the same with shopping cart, order, and payment. Providers such as Contentful, Strapi, or Shopify explicitly advertise this approach.

In reports about software companies, the term usually appears as a selling point. What is meant is: our product can be integrated into any existing environment. For investors, this is relevant because such systems can be more easily connected to other providers. This increases the number of potential customers.

The principle is also widespread in the AI world, though rarely under this name. A language model runs on a server and is addressed via an interface. Whether the answer ends up in a chat window, in a word processor, or in a customer service phone call is irrelevant to the model. Incidentally, the term “headless” in technology is also related to a second meaning: a server without a screen and keyboard is likewise called headless.