The question rarely arrives as a question. It arrives as a statement: "We want to go headless." Behind it there is almost always something concrete -- a customer portal that only fits the standard template under duress, a field sales application, a counter terminal at a branch, a catalogue with six-figure item counts. The architecture is merely the answer to a question that should come first: how many output channels are supposed to be served from one catalogue, and who operates them three years from now? This article sorts out the terms, names the four drivers that genuinely argue for decoupling in B2B, states the counter-calculation openly -- and shows the hybrid route that most mid-market projects are better served by.
Key takeaways
- Headless means a decoupled frontend talking to the Store API, composable means a modular system landscape, API-first means functions exist as interfaces first. A shop can be composable and still run the standard storefront.
- Four situations justify decoupling on their own: more than two output channels on one catalog, portal logic far outside the standard, very large variant-rich catalogs with a dedicated search layer, and a permanently staffed frontend team.
- A custom frontend shifts work rather than saving it: duplicate maintenance, a second deployment pipeline, a feature gap against built-in tools, and full SEO responsibility for rendering, status codes, canonicals and hreflang in your own code.
- The hybrid cut keeps public category and product pages on the server-rendered standard storefront and builds only the customer portal, quick order entry, configurator or dashboards as separate apps – behind the login the SEO risk disappears.
- Decoupling is not automatically faster: the yardstick stays LCP 2.5 seconds, INP 200 milliseconds and CLS 0.1 at the 75th percentile (Google web.dev). Customer-specific prices also reduce the HTTP cache hit rate.
- Full decoupling only carries when channel count, team and operating budget come together; if one is missing, the standard stays more economical (project experience). Rebuild in stages: PIM and ERP data contracts first, then one area behind the login.
Three terms that do not mean the same thing
Headless describes exactly one thing: the frontend is separated from the shop application and obtains data and functions through an API. In Shopware that is the Store API. According to the vendor it represents the customer-facing surface of the platform, delivers JSON over HTTP and thereby enables standalone frontends such as single-page applications or native apps (Shopware Developer Documentation). One detail from the same source matters for risk assessment: the standard storefront and API consumers rely on the same underlying services (Shopware Developer Documentation). Business logic is therefore not duplicated -- what is duplicated is the presentation layer.
Headless
A decoupled frontend talks to the shop through the Store API. Cart, prices, availability and checkout stay in the backend, while the interface is built and deployed independently.
Composable
Several systems are assembled modularly: shop, PIM, ERP, editorial system and search layer. That is a statement about the system landscape, not about the frontend.
API-first
Functions are available as interfaces before any interface exists. In Shopware this already applies as standard and is not a decision that still needs making.
The distinction is not pedantry; it has cost consequences. A shop can be headless without being composable -- a custom frontend on a single platform. And it can be composable without being headless: standard storefront in front, but clean interfaces to ERP, PIM and search behind it. The second case is the norm in the mid-market, and it is considerably cheaper to run. How far integration discipline currently reaches is shown by the B2BEST Barometer: 51 percent (ECC Köln) of the wholesalers and manufacturers surveyed connect their systems through rigid point-to-point links, while only 35 percent (ECC Köln) use API management. Anyone who wants to become modular on that basis builds the integration layer first -- not the frontend.
The question before the technology question
Four drivers that genuinely argue for headless in B2B
The digital channel has long been the main route in business-to-business trade: 83 percent (Gartner) of B2B buyers prefer to order and pay digitally, and Gartner expects around 60 percent (Gartner) of e-commerce companies to follow a composable approach by 2027. It does not follow, however, that every company needs its own frontend. In project practice, four constellations carry the decision -- individually, not as a sum of half-arguments.
Several output channels on one catalogue
Shop, customer portal, field sales application, kiosk or counter terminal and a punchout catalogue inside the procurement system all access the same items, prices and stock. From the third genuine channel onwards, the shared API becomes load-bearing structure rather than an add-on.
Portal logic far away from the standard
Framework agreements, budget limits, multi-step approvals, cost centres, project orders: when the interface is more administration than catalogue, a template works against the requirement. Such areas sensibly emerge as separate applications in B2B portal development.
Very large, variant-rich catalogues
With hundreds of thousands of items carrying technical attributes, a dedicated search layer handles filtering, facets and part-number logic. The frontend then consumes several services anyway -- decoupling follows the data situation.
An existing frontend team with its own stack
Where a development team already works with its own toolchain, design system and release process, a decoupled frontend is not extra effort but a continuation of existing practice. Without that team, the effect reverses.
The second and third points are the most common in the mid-market. The fourth is the most honest one: without permanently available frontend competence, decoupling turns into concentration risk. The barometer supports that caution -- 38 percent (ECC Köln) of the companies surveyed name a shortage of IT staff as an obstacle, and 39 percent (ECC Köln) cite the high cost of maintaining infrastructure. At the same time 34 percent (ECC Köln) report limited mobile access to their systems, which explains the appetite for field sales and terminal applications but also sharpens the staffing question.
- More than two output channels needing the same catalogue are concretely planned -- scheduled, not merely wished for
- The special area deviates so strongly in data model and interaction logic that template adjustments become a permanent building site
- A dedicated search layer is already in use or unavoidable, for instance because of part-number search and zero-result avoidance
- Frontend development is staffed as a role, not planned as project stopgap capacity
- An operating budget exists for two deployment and update tracks, reaching beyond the project period
The counter-calculation: what is added permanently
A decoupled frontend does not halve the work; it distributes it differently. Whatever arrives with platform updates in the standard storefront becomes your own task in your own frontend -- permanently, not once. These items belong in every effort estimate because they burden operations rather than the project.
- Duplicated maintenance: two applications with their own dependencies, security updates and release cycles. A Shopware update can require frontend adjustments whenever API responses change
- SEO responsibility: server-side rendering, status codes, redirects, canonicals, hreflang annotation and structured data sit in your own code
- Feature gap versus platform tools: shopping experiences, landing pages, merchandising functions and ecosystem extensions apply to the standard template, usually not to a custom frontend
- Dependency on frontend know-how: the area can hardly be looked after on the side; holidays, staff changes and illness become operating risks
- Higher running costs: an additional runtime environment, build and deployment pipeline, monitoring, error tracking and a second security process
The SEO point is underestimated most often. Google processes JavaScript applications in three steps -- crawling, rendering, indexing -- and queues pages for it: "The page may stay on this queue for a few seconds, but it can take longer than that" (Google Search Central). The recommendation from the same source is unambiguous: "Server-side or pre-rendering is still a great idea because it makes your website faster for users and crawlers, and not all bots can run JavaScript" (Google Search Central). Translated: a decoupled frontend for public category and product pages is feasible, but it requires server-side rendering, clean linking through real anchors with href attributes and a team that actively owns these topics. How closely loading behaviour and visibility are connected is covered by our performance optimization for B2B stores.
What ships with the platform has to be rebuilt otherwise
The hybrid middle path
Between "everything stays as it is" and "we rebuild everything" lies the route most B2B projects actually need. The standard storefront remains in place for the home page, categories, product details, content and checkout -- that is, for everything public, indexable and functionally well covered. Only individual areas are built as standalone applications on the Store API, exactly where the standard visibly reaches its limits. For such frontends Shopware provides its own reference implementation based on Vue and Nuxt, including an API client and composables that consume the Store API (Shopware Developer Documentation).
Customer portal behind the login
Order history, framework agreements, approvals, open items and documents. The area is not indexable anyway -- the SEO argument against headless disappears entirely here. Details in the article on B2B customer portals and self-service.
Quick order and order lists
Part-number entry, CSV import, recurring carts: a keyboard-driven form that is fundamentally different from a catalogue interface and benefits from its own state logic.
Configurator and variants
Multi-step selection with rules, dependencies and price determination. Such flows are applications rather than pages -- and they benefit from a dedicated frontend far more than a category page does.
Dashboard and reporting
Purchasing volume per cost centre, budget levels, delivery status. Data-heavy views with filters and tables are the classic case for a separate application behind the login.
The economic advantage of this cut lies in how risk is distributed. The search-relevant surfaces stay server-rendered and under the platform's responsibility, while the additional effort arises exactly where it creates measurable benefit. If the portal team is unavailable, the sales channel keeps running -- the shop still sells. This separation is also cleaner in budget terms, because the special area can be costed as its own item and expanded stage by stage in B2B customer portal development.
The most expensive architecture is the one chosen for a single area and then made binding for everything.
Architecture: data flow, caching and sessions
Regardless of the frontend model, the data flow remains the actual work. Master data and media come from the PIM, prices, stock and documents from the ERP, and orders travel the same route back. In this chain the shop is not a data household but a distributor with a contract -- and in the headless case that contract is the API. Fundamental design patterns are described in the article on interface architecture in B2B; the concrete implementation belongs to interface and integration work.
- PIM delivers the description: attributes, classifications, media, copy and translations -- complete and versioned, not as an ad-hoc export
- ERP delivers the facts: prices including customer and volume conditions, stock, delivery times, credit limits and document status
- Delta synchronisation instead of full imports: timestamps or change counters limit the load; full reconciliations run as a plannable special case
- Index and search layer: facets, part-number logic and sort orders are prepared so the frontend does not compute on every request
- The frontend consumes the Store API: catalogue, cart, customer account and checkout run through the same services as the standard storefront
- Return flow into the ERP: orders, customer records, address changes and payment information flow back -- including the freight logic covered in detail by the article on calculating shipping and freight costs in a B2B shop
Caching is where B2B becomes uncomfortable. Shopware calls the HTTP cache "a must-have for every production system" in its own documentation and recommends an upstream reverse proxy cache for production systems; for the object cache a memory-based adapter is recommended over file storage (Shopware Developer Documentation). In addition, caching and lifetimes of individual Store API routes can be steered through cache policies (Shopware Developer Documentation). The B2B catch: customer-specific prices, quotas and visibilities personalise almost every response. What stays cacheable is mainly structure and description, while price and availability are loaded separately. Invalidation via cache tags needs its own operating routine, because orphaned entries otherwise fill up memory over time (Shopware Developer Documentation).
The third classic topic is login and session. The Store API works with an access key per sales channel and carries session state -- cart, login, context -- through a context token; anonymous and authenticated access are explicitly foreseen (Shopware Developer Documentation). With corporate customers the organisational level is added: several users per customer account, different roles, approval limits and cost centres. If the frontend runs on a different host than the shop, cookie domain, SameSite behaviour, token lifetime and the transition between portal and checkout belong in the architecture sketch -- not in the test phase.
Permissions belong in the backend
Performance: headless is not automatically faster
The expectation that a decoupled frontend is faster per se rarely survives measurement. The yardstick is the Core Web Vitals with their thresholds: 2.5 seconds for Largest Contentful Paint, 200 milliseconds for Interaction to Next Paint and 0.1 for Cumulative Layout Shift, each assessed at the 75th percentile of page loads and segmented by mobile and desktop (Google web.dev). That is the bar -- irrespective of the architecture working behind it.
How hard the bar is to clear is shown by field data: 43 percent (HTTP Archive Web Almanac) of websites achieved good values across all three metrics on mobile, and 54 percent (HTTP Archive Web Almanac) on desktop. Looking at individual metrics, 59 percent (HTTP Archive Web Almanac) reached a good LCP on mobile, 74 percent (HTTP Archive Web Almanac) a good INP and 79 percent (HTTP Archive Web Almanac) a good CLS. The bottleneck therefore sits mostly in how the largest content loads -- an area a frontend swap alone does not solve.
Google's rendering documentation states the trade-offs clearly. Server-side rendering saves delivered JavaScript: "Running page logic and rendering on the server lets you avoid sending lots of JavaScript to the client" -- but it costs time to first response: "Generating pages on the server takes time, which can increase your page's TTFB" (Google web.dev). For purely client-side rendering the opposite applies: "The amount of JavaScript required tends to grow as an application grows, which can impact a page's INP" (Google web.dev). And hydration has its own trap: server-rendered pages can appear loaded without responding to input as long as the matching scripts have not executed (Google web.dev).
- Server response time: an additional network hop between frontend server and Store API lengthens the path instead of shortening it
- Image strategy: formats, size variants and prioritising the LCP element matter more than the framework underneath
- JavaScript volume: as the application grows, response time grows with it -- especially on the devices used in the warehouse and in field sales
- Cache hit ratio: personalised responses reduce the effect of the HTTP cache; the strategy has to separate structure from personalisation
- Payload per view: a facet filter across many variants is expensive in the backend -- regardless of who renders the interface
The discussion only becomes solid with field values from your own shop. Which levers measurably work in a Shopware environment, and in which order they make sense, is covered in the article on performance optimization for B2B stores.
Decision matrix: three routes, six criteria
The following matrix is not a scoring system but a sorting aid. In practice a single criterion rarely decides; what decides is which row sets the hardest limit in your own organisation -- usually team size or operating budget, not technical feasibility.
| Criterion | Standard storefront | Hybrid approach | Fully decoupled |
|---|---|---|---|
| Output channels | one channel, classic shop | shop plus one or two special areas | three or more channels on one catalogue |
| Team size | agency or a single internal role | backend team plus selective frontend capacity | own frontend team with permanent responsibility |
| Budget | build and operation within the standard frame | extra budget only for the special area | budget for building and running two applications |
| Time to market | short, platform tools cover the standard | medium, the shop keeps running during the build-out | long, the frontend is built before the first revenue |
| Operating effort | one deployment, one monitoring setup | two deployments with clearly separated responsibility | two stacks, two update cycles, two security processes |
| SEO risk | low, rendering and metadata come from the platform | low, public surfaces stay server-rendered | elevated, rendering, canonicals and hreflang sit in your code |
A reading aid for practice: anyone landing in the left column in four out of six rows has the more economical solution with a well-maintained standard storefront and clean integration -- including the B2B functions that Shopware in the open-source variant already brings along. Anyone predominantly in the middle column should isolate the special area instead of switching the overall architecture. The right column carries its weight when channel count and team and operating budget come together -- if one of those three rows is missing, the rebuild tends to cost more than it returns (project experience).
A migration path in stages instead of a big bang
Once the decision for decoupling is taken, the sequence determines the risk. Replacing the entire interface at once ties up budget for months without a single visible benefit in that time. A staged route inverts this: each stage can be accepted on its own, and stopping remains a viable option at every point.
- Inventory: channels, special logic, integrations, extensions and their actual usage -- including the question of which platform tools would be needed in the frontend
- Tighten the data contracts: stabilise PIM and ERP routes before a second interface accesses them
- Isolate the first area: usually the customer portal or quick order -- behind the login, without SEO risk, with a clearly defined user group
- Set measuring points: capture field values, error rate, processing time per order and support effort before and after the switch
- Attach the second channel: field sales application, terminal or punchout route on the same services -- only here does the scale effect appear
- Assess public surfaces last: decouple category and product pages only once rendering, metadata and redirects demonstrably work in your own frontend
This order has a pleasant side effect: the first two stages pay into any architecture. Anyone who completes them and then stays with the standard storefront has not burned money but repaired the integration layer. It is worth looking at obligations that are due anyway -- for instance the AI labelling obligations for B2B shops, which have to reappear in a custom frontend just as they do in the standard template.
Two numbers for budget planning
How an architecture assessment works
We set up a compact assessment before such decisions, because the question "headless yes or no" cannot be answered seriously without numbers. The effort is in the range of a few days and ends with a written recommendation that also holds up in front of management -- including the variant in which the rebuild is not recommended at this time.
- Channel and requirement inventory with a time horizon, separated into public and logged-in areas
- Inventory of extensions, template adjustments and integrations including their actual usage
- Assessment of the PIM and ERP data routes including delta capability and error handling
- Field values on current performance as a baseline instead of lab figures
- Recommendation with effort and operating cost estimates for all three routes of the decision matrix
- Stage plan with stopping points, metrics and responsibilities per stage
The result is either a cleanly cut special area, a decoupled frontend with a clear operating model, or a reasoned recommendation to stay with the standard and strengthen the integration layer instead. What we implement technically is described on the service page for headless commerce with Shopware; if you would like your starting position assessed concretely, a conversation about your architecture plans is the fastest route to a defensible number.
Sources and Studies