When you are planning or evaluating a headless project today, you encounter a particular narrative: break up the monolith, separate frontend and backend, use best-of-breed services for commerce, search and content. And then, logically, so the story goes, you get agility, speed, scalability.

This narrative is half correct. The backend part holds. The frontend part does not.

Kelly Goetsch describes the goal of true omnichannel in Microservices for Modern Commerce (O'Reilly, 2016) as: a single backend system per business capability, and on top of that, UIs that are "more or less disposable." New user interfaces, for new channels, new devices, new contexts, would then be assembled quickly from finished APIs.

This "disposable UIs" thesis is the most costly misconception carried forward from that eBook. And it explains why so many headless projects produce more frontend code than the monoliths they were meant to replace.

What backend microservices actually solve

Let us first understand what headless genuinely solves, because it is real.

Goetsch is right that horizontal coupling in the monolith backend is the primary brake on commerce development. The classic Shopware 6 monolith or an SAP Commerce deployment means: pricing, inventory, promotions, cart logic and CMS all live in the same deployment artefact. A change to the promotions engine requires a full release. A new category page in the CMS means backend deployment coordination.

Headless resolves this structurally. Commercetools manages pricing, promotions and cart independently from one another. Algolia is exclusively responsible for search. Contentful or Hygraph for content. Each of these services has its own deployment cycle, its own team, its own roadmap. The backend disaggregation works.

Goetsch describes this as "systems of record for each bit of functionality (pricing, promotions, products, inventory, etc.)", and practice in 2026 gives him full marks. No serious commerce organisation above a certain volume still runs a single backend system for all of these functions.

What backend microservices do not solve: the new frontend bottleneck

Here is the problem. As soon as the backend consists of dozens of microservices, the frontend has to coordinate them. And that coordination is not trivial.

A typical composable storefront needs to handle the following:

Data aggregation: A single product page requires data from the product microservice (commercetools), the inventory service, the pricing service, the reviews service and the CMS. That is at minimum five separate API calls that need to be coordinated, cached and error-handled.

Caching strategy per data type: Product descriptions can be aggressively cached. Inventory must be read fresh at checkout entry. Prices must be invalidated immediately after a promotion trigger. In most projects today, this caching policy is distributed across page templates, middleware layers and edge functions, nobody has designed it as a whole.

Personalisation near-render: If personalisation happens only in the backend, you lose edge performance. If it happens in the frontend, the frontend has to carry the personalisation logic. That is not a small concern.

A/B testing infrastructure: In the monolith you had a single deployment artefact that could be versioned. In the composable storefront you have frontend code that spans A/B variants across multiple microservice calls. That requires its own infrastructure.

Multi-market deployment: GB, DE, US, AU, each localisation with its own pricing, content, promotions and navigation. In the monolith this was all in one system. In the composable stack you have to coordinate it across every layer.

Performance budget management: Core Web Vitals are a ranking factor. A composable storefront that fires ten API calls in parallel and renders their responses has a structural performance problem that the monolith with server-side rendering never had.

All of this is genuine frontend work. And it is not smaller than the backend work of the old monolith. It is just distributed differently, and because it sits in the frontend, it is less visible in traditional backend-focused IT budgets.

The disposable UI illusion in practice

Goetsch writes that new UIs can be built "in a few days" once the backend APIs are in place. In a simple demo environment this is true. In a production environment with real requirements it is not.

What actually happens: every new frontend touchpoint, mobile app, kiosk, international market, new channel, inherits the full coordination complexity of the backend setup. You are not simply building a new UI on top of finished APIs. You are building a new UI that:

• Knows and implements caching policies for every microservice it uses
• Contains personalisation logic appropriate to the context of the new touchpoint
• Brings or consumes A/B testing infrastructure
• Meets performance budgets for the new channel
• Includes error states and circuit-breaker logic for every API call

That is not a few days of work. That is a full frontend project, every time.

The paradox: the more backend microservices you have, the greater the coordination complexity in the frontend. The backend disaggregation that was supposed to make you faster makes your frontend slower.

What "outer architecture for the frontend layer" means

Goetsch describes the Outer Architecture of microservices in Chapter 4: the layer that sits between microservices and handles container orchestration, service discovery, API gateways and eventing. He writes: "Outer architecture is best handled by a single team that is composed of your best programmers."

The analogy for the frontend layer is direct: you need an outer architecture for the frontend layer, a tier that standardises coordination between backend microservices and frontend rendering, without every page template having to re-implement that logic.

That is what a Frontend Management Platform (FMP) does. It takes on:

• Composition layer: Which data sources are aggregated for which page? Defined declaratively, not rebuilt in every page template.
• Caching policy standard: Declarative caching rules per data type, instead of distributed middleware logic.
• Deployment infrastructure: Frontend deployments without backend coordination, rollback-capable, edge-deployed.
• Performance budget enforcement: Core Web Vitals as a first-class constraint, not a post-hoc audit.
• Personalisation layer: Near-render personalisation without custom middleware per touchpoint.

This is not another CMS. This is the container orchestration for your frontend layer.

Why this is especially relevant for Shopware and commercetools projects

The two most common headless migration scenarios in 2026 are:

Shopware headless: Shopware 6 provides a clean API layer. Many merchants migrate the frontend to Next.js or Nuxt.js while retaining Shopware as the backend system. The result: fast backend, complex custom frontend. Without a frontend layer standard, separate frontend implementations emerge per market and per channel.

commercetools stack: The commercetools stack is excellently modular on the backend side. But precisely because everything is API-first, the frontend is the only place where composition happens. Without an FMP, that composition logic lands in the Next.js project, and grows without constraint.

A Laioutr headless frontend for Shopware or for commercetools addresses exactly this gap: a pre-configured frontend layer that standardises composition and caching logic, so you do not start from scratch on every project.

TCO: what a custom build actually costs

The most common miscalculation in headless projects is the TCO comparison. Frontend teams often compare the initial development time of a custom frontend with the licensing fee of an FMP, and the custom build wins at first glance.

What is not included:

• Ongoing maintenance of the custom composition layer (every backend API change breaks something)
• Performance optimisation (Core Web Vitals degrade with every new feature addition)
• Developer onboarding (new team members must understand the proprietary composition framework)
• Multi-market expansion (every new localisation scales the custom build proportionally)
• A/B testing infrastructure (often rebuilt as a separate project)

An FMP model has higher initial costs, but a considerably flatter TCO curve over two to three years, because composition logic, caching and deployment infrastructure do not need to be rebuilt.

If you want this calculation in detail: request a TCO comparison.

Conclusion: headless needs a frontend layer standard

Microservices for Modern Commerce accelerated the commerce stack, but its backend-only focus left a generation of headless projects with a structural frontend problem.

The problem is solvable. But it is only solvable if you treat the frontend layer with the same architectural seriousness as the backend layer. That means: its own outer architecture, its own caching standards, its own deployment infrastructure, its own ownership.

Without that, headless will not be faster than the monolith. It will just be more expensive.

[Frontend layer as FMP, request a TCO comparison](https://www.laioutr.com/demo)

Source: Goetsch, K. (2016). Microservices for Modern Commerce. O'Reilly Media.

Related Insights

• The Missing Layer in Composable Commerce: Why You Need Frontend Orchestration
• How Headless CMS Personalization Transforms the Frontend Experience in Composable Commerce

Related resources: Composable Headless Frontend.