Going headless buys you control of the front end and costs you everything the platform used to do for free. For B2B there are three situations where that trade is clearly right, and a much larger set where a well-built themed storefront wins.
Headless is an architecture, not an upgrade. Decoupling the storefront from the platform hands you the front end entirely — routing, rendering, caching, state, accessibility, SEO, the build pipeline and the hosting. Every one of those was previously somebody else’s problem.
That trade is sometimes clearly correct. It is more often chosen because it sounds like the modern answer, and the bill arrives eighteen months later when the person who built it has moved on and nobody wants to touch the rendering layer.
The three cases where it pays
The buying experience is genuinely not a catalogue
Configurators, complex quote builders, CAD or spec-driven selection, order pads that behave more like spreadsheets than product grids. When the interface is the product, theme constraints become the binding constraint.
One commerce backend serves several very different front ends
A trade portal, a retail site, a field-sales application and a customer service tool sharing one catalogue and one pricing engine. Here decoupling is not a preference — it is the only sane structure.
Content and commerce are equally weighted
Technical documentation, specification libraries and application guides that must live alongside purchasing. A headless front end over both a CMS and the commerce API composes this cleanly; a theme fights it.
What you are taking on
The honest way to make this decision is to list what moves from the platform’s responsibility to yours, and then ask whether your team wants those jobs.
| Responsibility | Themed storefront | Headless |
|---|---|---|
| Checkout | Platform-hosted and maintained | Platform-hosted, handoff is yours |
| Performance | Platform defaults + theme quality | Entirely yours, including caching |
| SEO fundamentals | Largely handled | Entirely your implementation |
| Accessibility | Theme baseline to build on | Entirely yours |
| New platform features | Arrive automatically | Require integration work |
| Hosting & deploys | Included | Your infrastructure |
| Time to launch | Weeks | Months |
Performance is not automatic either
Headless is frequently sold on speed. It can be faster — but only with a deliberate caching strategy. A React storefront that fetches pricing per component on every render is slower than the theme it replaced, and B2B makes this harder, because personalised pricing resists the edge caching that makes DTC headless builds fast.
The workable pattern is to split the page by cacheability: cache the catalogue shell aggressively at the edge, and hydrate the account-specific parts — price, availability, entitlements — in a single batched request. One request for the personalised layer, not one per card.
Bar chart of request counts to render a B2B category page of thirty products. Naive headless implementation with per-component pricing fetches makes thirty-one requests. Batched personalisation makes two requests. A themed storefront makes one request.
The middle path most teams should take
Both major platforms now offer opinionated frameworks — Hydrogen and Oxygen on Shopify, Catalyst on BigCommerce — that hand back a good deal of what you would otherwise own. Routing, data fetching conventions, caching primitives and deployment come with sensible defaults.
And you do not have to go headless everywhere. Running a themed storefront for the catalogue and a decoupled application for the one genuinely complex surface — the configurator, the quote builder, the order pad — captures most of the benefit for a fraction of the surface area. That hybrid is what we recommend most often, and it is rarely what teams arrive asking for.
Key takeaways
- Headless transfers the front end to you in full: performance, SEO, accessibility, hosting and platform-feature integration.
- It pays when the interface is the product, when several front ends share one backend, or when content and commerce are equally weighted.
- Personalised B2B pricing resists edge caching — split the page by cacheability and batch the personalised layer.
- Most post-headless traffic drops are caused by SEO the theme used to emit silently.
- A themed catalogue plus one decoupled complex surface is usually the better trade than going fully headless.
360 Expert Solutions
E-commerce & ERP Integration Team
We build and scale B2B and DTC commerce on Shopify Plus, BigCommerce and WooCommerce, wired into NetSuite and Oracle. These articles are written by the engineers and architects who deliver those projects.
Building something like this?
We architect B2B commerce and ERP integrations end to end.