What composable commerce actually means
Composable commerce is an architecture where the ecommerce stack is assembled from specialised, independently chosen services. The commerce engine handles transactions and orders. A PIM handles product data. A CMS handles content. A search provider handles discovery. A payment service handles checkout. Each service is picked on its own merits, and they are connected through APIs instead of coming bundled from a single platform vendor.
This contrasts with the monolithic model, where one platform provides commerce, catalog, content, search, and checkout as integrated features. Monolithic platforms optimise for speed of delivery and tight feature integration. Composable optimises for flexibility and the ability to pick best-of-breed in every layer.
Composable vs. headless vs. monolithic
These three terms overlap but describe different things. A monolithic platform bundles commerce, catalog, content, and storefront into one system — Shopify Standard, Magento with native frontend, or legacy Episerver. It is fastest to deliver and cheapest for simple requirements.
Headless means the frontend is decoupled from the commerce backend through APIs. The backend can still be a monolithic platform. Headless Shopify or headless Magento with a custom Next.js frontend are common patterns. Headless gives frontend flexibility without changing the commerce backend.
Composable goes one layer deeper. Not only is the frontend decoupled, but PIM, CMS, search, payment, and sometimes ERP integration are each their own service. Composable is inherently headless, but headless is not inherently composable. The distinction matters when you plan the delivery — composable requires integration architecture that headless-only projects do not.
When composable commerce pays off
Composable is not the right answer for every business. The added delivery complexity, longer integration work, and higher licence count only pay back in specific scenarios:
- Multi-brand or multi-market complexity — When different brands or markets need different frontends, content models, or commerce rules, a composable stack lets you share the commerce engine while varying everything above it. Duplicating a full monolithic platform per brand or market is more expensive long-term.
- Specialised requirements in individual layers — If search is strategic (thousands of SKUs, technical attributes, configurators), a dedicated search provider like Klevu or Algolia outperforms bundled platform search. The same applies to PIM, CMS, and advanced pricing.
- Multi-year evolution plans — If the roadmap involves replacing individual services over several years, composable makes that incremental rather than a full re-platform each time.
- B2B with deep complexity — Contract pricing, approval workflows, and ERP integration tend to outgrow what monolithic platforms handle natively. The B2B ecommerce guide covers why composable often becomes the right fit at scale.
If the business is a single-brand D2C shop with a straightforward catalog, the added complexity is rarely worth it. A well-configured Shopify or Shopware setup delivers faster and costs less to run.
What a composable stack looks like in practice
A typical Nordic composable ecommerce stack includes five to seven services:
Commerce engine — handles product catalog, pricing, inventory, cart, and order creation. Norce and commercetools are common choices. The commerce engine is the backbone.
PIM — owns enriched product information, translations, channel-specific content. Akeneo and inRiver are typical picks. The PIM guide covers selection criteria in depth.
CMS — handles editorial content, campaigns, and storytelling. Storyblok and Contentful fit natively into composable architectures. The CMS is where content teams work without touching commerce data.
Search and personalisation — Klevu, Algolia, or Nosto handle discovery and recommendations. This layer is often what drives conversion more than the commerce engine itself.
Payment — Adyen, Svea, Briqpay, or Walley depending on whether the focus is consumer, B2B, or multi-market. Payment is its own specialised service in composable setups.
Frontend — typically Next.js, Nuxt, or a dedicated storefront like Frntkey. The frontend orchestrates all the services into the customer experience.
ERP integration — the commerce engine and PIM sync with the ERP for pricing, inventory, and orders. See our ERP integration guide for how this layer works in practice.
The integration layer decides whether composable delivers
The hardest part of composable commerce is not picking the services. It is connecting them reliably. Each service exposes its own API. Product data flows from PIM to commerce engine to frontend. Inventory flows from ERP to commerce engine to every channel. Orders flow from frontend to commerce engine to ERP. Pricing rules, promotions, and customer segments cross multiple services.
When these flows are built as point-to-point integrations, complexity grows with every service you add. A middleware or integration layer that acts as a central hub keeps this manageable. Junipeer is the integration layer Nordic Web Team uses for ERP and transactional system integration. For pure API-to-API flows between commerce services, event-driven patterns work well — but they require architectural thinking that a monolithic project does not.
This is the hidden cost of composable commerce. The services are easy to list on a slide. The integration work is where delivery timelines and budgets are set.
Platforms and composable readiness
Norce is built API-first. The commerce engine separates cleanly from frontend, PIM, and other services. It is a natural fit for composable in Nordic B2B and multi-brand scenarios. Frntkey serves as the headless storefront.
Shopware supports composable through its API-first architecture and open-source core. It can function as the commerce engine in a composable stack while remaining usable as a near-monolith for simpler needs. This dual profile makes Shopware a pragmatic choice.
Magento with Hyvä can be used composably, particularly with Hyvä's progressive decoupling of frontend and backend. Full composable with Magento as the commerce engine requires more integration work than Norce or Shopware.
Shopify Plus can serve as the commerce engine in a composable setup, though Shopify's strength is its integrated platform experience. Going composable with Shopify often means giving up some of what makes Shopify attractive in the first place.
Monolithic, headless, or composable — how to decide
The right architecture is not a question of which is most modern. It is a question of fit.
Choose monolithic when the business is single-brand, single-market, with a straightforward catalog and no immediate plans for multi-channel expansion. Shopify Standard or a well-configured Shopware setup delivers fast and runs cheaply.
Choose headless when the frontend needs more flexibility than the platform provides — custom design, app-like experiences, or specific performance requirements — but the commerce backend is still a good fit.
Choose composable when multiple layers of the stack have specialised requirements, when the business runs multiple brands or markets, when deep B2B complexity is a core part of the model, or when a multi-year evolution plan makes incremental replacement more valuable than a single re-platform.
The worst outcome is choosing composable for hype and delivering twelve months late because the integration architecture was underestimated. Composable is a delivery commitment, not a feature.
Want to talk through your specific architecture? Read our headless commerce guide or the B2B ecommerce guide for how composable fits into broader delivery decisions.