Composable Commerce in B2B: When It's Right and When It's Not

Composable commerce has become one of the most discussed architectural concepts in the industry. The promise is compelling: pick the best components for each capability, compose them into a tailored stack, and gain the flexibility to evolve each piece independently.

But for B2B organisations evaluating SAP Commerce Cloud, the question isn’t whether composable is theoretically superior — it’s whether the trade-offs make sense for your specific context.

What “Composable” Actually Means in the SAP Context

In SAP Commerce Cloud terms, composable commerce typically means:

• Commerce engine: SAP Commerce Cloud handles product content, pricing, order management, and stock
• Storefront: A decoupled frontend — Spartacus, a custom React/Vue.js app, or a DXP like Contentful or Sitecore
• Experience layer: Personalisation, A/B testing, and content management handled by dedicated tools

The key technical enabler is SAP Commerce Cloud’s OCC (Omnichannel Commerce) API layer, which exposes all commerce capabilities as REST APIs.

When Composable Makes Sense

High design and UX ambition. If your storefront needs to be a genuine brand experience — not a functional catalogue — composable gives your design and frontend teams the freedom to build exactly what’s needed without fighting the platform.

Multiple storefronts. If you’re running B2B and B2C experiences, or storefronts for multiple brands or markets, decoupling the frontend lets each experience evolve independently from a shared commerce core.

Aggressive release cadence. When the business needs to ship frontend changes multiple times per week, separating the storefront from the commerce engine means backend and frontend releases are decoupled.

When Composable Doesn’t Make Sense

Small teams with no dedicated frontend capability. Composable commerce requires frontend expertise. If your team is primarily SAP/backend-focused, you’ll spend more time managing the frontend stack than building commerce features.

Short timelines. A composable architecture takes longer to deliver. For a project with a 6-month deadline, an accelerator-based approach on Spartacus will typically be faster.

Simple catalogue and ordering requirements. If the core use case is a functional B2B order portal with standard features (not a flagship brand experience), the added flexibility of composable may not justify the complexity.

Our Recommendation

For most B2B SAP Commerce Cloud projects we see, a pragmatic middle ground works best:

• Use SAP Commerce Cloud as the commerce engine
• Use Spartacus as the frontend accelerator (customised as needed)
• Add Emarsys or a DXP for personalisation and content management
• Adopt composable incrementally as team capability and business complexity grows

The “fully composable” architecture is genuinely the right answer for some organisations — but it’s not the default. The right architecture is the one that fits your team, timeline, and business model.

Want to discuss which approach is right for your organisation? Talk to our commerce architects.