Posted in Digital Commerce
June 8, 2026
Field analysis
A Shopware manufacturer goes decoupled without going fully composable
Villeroy and Boch is a long-established European manufacturer whose Shopware deployment is documented in Shopware's customer story library. The case is a clean example of how a B2B manufacturer can go decoupled on Shopware without taking on full composable. This analysis reads the case from an architecture standpoint and names the trade-offs that come with stopping short of composable.
Key takeaway
Decoupled-without-composable is a defensible stopping point. The Shopware commerce engine stays intact; the frontend runs independently; the composable conversation gets deferred until the business logic genuinely demands it.
In this case study
- Refreshed brand expression on the storefront frontend
- Faster page experience after decoupling the frontend
- Clearer multi-channel coordination across European markets
- Shopware commerce engine retained without breaking apart into separate services
Acro Commerce’s architectural read on the Villeroy and Boch customer story published by Shopware. Read the original case study on www.shopware.com
Customer profile and architectural starting point
The published Villeroy and Boch case describes a manufacturer with a deep heritage in ceramics and lifestyle products, running B2B and B2C channels across multiple European markets. The starting point is a mature commerce operation with significant brand investment, where the frontend experience is a meaningful part of the brand promise.
The architectural question for a manufacturer at this scale is rarely whether to modernize the commerce engine. Shopware's B2B suite and broader platform features cover most of the operating model. The question is how to give the frontend the flexibility to express the brand without rebuilding the rest of the stack. Decoupled is the natural answer; full composable is the next question, with a different answer.
Why composable was rejected
For a manufacturer whose commerce engine already fits the business and whose investment in Shopware is multi-year, a full composable rebuild would have meant breaking apart a working commerce engine into separate services for cart, search, identity, and more. The integration cost would have been substantial; the benefit would have been marginal because the commerce engine was not the constraint.
The smaller decoupled shape (custom frontend, Shopware backend intact, content layer added where useful) gives the team the brand-led experience flexibility without taking on the operational cost of running every commerce role as a separate vendor. This is the pattern we see most often for B2B manufacturers whose commerce engines are working.
Frontend and backend separation in practice
Decoupled in practice means a custom storefront application calling Shopware's Store API for catalogue, cart, checkout, and customer data, with the storefront running on its own runtime (Vercel, Cloudflare, or a similar edge platform). Shopware retains responsibility for the commerce engine and the admin experience; the frontend takes responsibility for performance, accessibility, structured data, and the rest of the experience layer.
The clean version of this pattern includes a thin BFF layer between the frontend and Shopware to aggregate calls, cache appropriately, and provide a stable contract that the frontend can rely on as the Shopware backend evolves. Without the BFF, the frontend is exposed to every API change Shopware ships; with it, the team has a buffer.
Outcomes and operating costs
The published Shopware case study describes the customer-facing improvements: a refreshed brand expression, faster page experience, and clearer multi-channel coordination. For a B2B manufacturer at this scale, those outcomes are the visible part of the architecture decision. The operating costs are the invisible part: one new application to run, one BFF to maintain, one additional codebase in the team's responsibility.
The operating cost is meaningfully lower than a full composable rebuild. A decoupled Shopware stack typically adds one or two operational responsibilities to the team's plate. A full composable rebuild typically adds five or six. For many B2B manufacturers, the smaller increment is the better trade.
Signals that would force a future move to composable
The conditions that would push a manufacturer like this toward composable later: the commerce engine genuinely cannot represent a critical business rule, even with custom development; catalogue complexity makes search ranking the buying experience and Shopware's native search cannot do the work; multiple distinct brands or markets need to share backend services through different frontends with different commercial models; or the team grows into multiple engineering groups that can sustain separate service contracts.
None of those conditions are present in the published Villeroy and Boch case. Until they are, the decoupled-without-composable stop is the right choice. The composable vs middleware decision frame walks through the broader version of this question for other manufacturers considering the same call.
Related Articles
Decoupled and composable commerce for complex B2B
- Definition: What is composable commerce?
- Definition: What is headless commerce?
- Definition: What is decoupled commerce?
- How a manufacturer modernized with Acumatica and a composable storefront
- A Shopware manufacturer goes decoupled without going fully composable
- The state of composable commerce for complex B2B in 2026
Frequently Asked Questions
Can you go decoupled on Shopware without going fully composable?
Yes, and the pattern is well-trodden. A custom storefront calls Shopware's Store API for catalogue, cart, checkout, and customer; Shopware retains the commerce engine and admin; a thin BFF layer aggregates calls. The team gets the brand-led experience flexibility without taking on the operational cost of running every commerce role as a separate vendor.
Why would a Shopware manufacturer reject full composable?
Because the commerce engine is not the constraint. Breaking apart a working Shopware commerce engine into separate services for cart, search, identity, and more carries substantial integration cost and marginal benefit when the engine already fits the business. The smaller decoupled shape delivers the flexibility manufacturers actually need.
What does a decoupled Shopware build typically include?
A custom frontend application (Next.js, Nuxt, or similar) on its own runtime, Shopware's Store API as the commerce backend, a thin BFF layer between the frontend and Shopware to aggregate calls and provide a stable contract, and often a headless CMS like Storyblok for content. Shopware retains the commerce engine and the admin experience.
What outcomes did the Villeroy and Boch Shopware deployment report?
The published case describes a refreshed brand expression, faster page experience, and clearer multi-channel coordination. These are typical of decoupled Shopware deployments where the brand-led storefront has been the constraint and the commerce engine has been working.
What operating cost does decoupled add over a templated Shopware build?
One new application to run (the custom frontend), one BFF to maintain, and one additional codebase in the team's responsibility. The operating cost is meaningfully lower than full composable, which typically adds five or six service relationships rather than one application.
When would a decoupled-without-composable Shopware build need to evolve to composable?
When the commerce engine cannot represent a critical business rule even with custom development, when catalogue complexity makes search the buying experience and Shopware's native search cannot do the work, when multiple distinct brands need to share backend services through different frontends, or when the team grows into multiple groups that can sustain separate service contracts.
Next Step
Get the foundation right before you build.
For readers scoping a platform decision or wanting a full architecture recommendation.