Pillar Overview
Decoupled and composable commerce for complex B2B
Composable commerce is an architecture pattern, not a destination. For a complex B2B manufacturer, it is sometimes the right answer, often overkill, and occasionally the wrong shape altogether. This pillar maps decoupled, headless, and composable as distinct ideas, names the business logic that justifies each one, and gives you a frame for choosing the smallest pattern that still carries the work. Architecture before app. Business logic before vendor selection.
The thesis
Composable is a strategy with trade-offs, not a religion. Pick the smallest architecture pattern that still carries your business logic, and add complexity only where it earns its keep.
What's in this guide
Twenty-four pieces, seven decisions.
Skim by topic. Each section maps to a decomposition decision in complex B2B commerce.
Next step
Pick the smallest architecture that still carries the work.
Celeste pressure-tests your composable assumptions in about three minutes.
Discovery and Strategy turns the result into a plan.
Decoupled and Composable Commerce
Frequently Asked Questions
What is composable commerce, in one paragraph?
Composable commerce is an architecture pattern that assembles a stack from independent best-of-breed services (cart, search, PIM, CMS, identity, payments, OMS) connected by APIs, instead of using a single monolithic platform for everything. It trades the convenience of a single vendor for the flexibility of swapping any one service later. For a B2B manufacturer, the pattern is the right answer when business logic does not fit a single platform's model, or when multiple channels or brands need to share backend services.
How is composable different from headless and decoupled commerce?
Headless separates the storefront UI from the commerce backend by talking through APIs. Decoupled goes further: the frontend runs on its own runtime and deploys independently. Composable goes further again: the entire stack is assembled from separate services, each chosen on its own merits. You can be headless without being decoupled, decoupled without being composable, and composable without being any single vendor's version of composable.
When does a B2B manufacturer actually need composable commerce?
When business logic genuinely does not fit a single platform, when multiple regions or brands need to share backend services, when catalogue complexity makes search the buying experience, or when an existing platform's order or pricing model has been outgrown. If a well-fit native platform plus a strong middleware layer can carry the load, composable usually is not the right answer.
What does composable commerce cost compared to a native suite?
In our work with mid-market manufacturers, composable typically costs two to four times what a well-fit native build costs over a three-year horizon, with operating cost the larger share. That includes platform fees, vendor contracts, integration work, and the engineering hours required to keep the service contracts current. The numbers vary widely with scope; the multiple does not vary much.
Do we need MACH to do composable?
No. MACH (Microservices, API-first, Cloud-native, Headless) is one well-known framing of composable, defined by the MACH Alliance. It is a useful reference shape, especially for vendor evaluation, but it is not the only shape. Many successful composable builds blend MACH-compliant services with a few non-MACH components where the trade-off is worth it.
Can composable hurt SEO and AEO for a B2B site?
Yes, if the frontend renders content only on the client. Google and AI engines both crawl rendered HTML, so a decoupled or composable site that ships an empty shell on first paint will look invisible to both. The pattern that holds visibility is server-side rendering at the edge, with client hydration for interactivity and structured data emitted in the HTML response.
What is the smallest version of composable that still helps?
Augmented: a well-fit native commerce platform with one or two best-of-breed services swapped in (usually search or CMS) and the frontend decoupled for independent release. This pattern gives marketing autonomy and frontend flexibility without taking on the full operational tax of running every service separately. Many B2B manufacturers settle here for good reason.
How does composable interact with our ERP?
The ERP almost always remains the operational source of truth for pricing, inventory, accounts, and order state, whether the storefront is monolithic, decoupled, or composable. Composable changes how many places call the ERP, not whether they should. The work that matters is the integration contract between the ERP and the services that read from or write to it. That work is the same regardless of architecture pattern.
What is a BFF and why do composable stacks need one?
A BFF (backend-for-frontend) is a thin server-side layer that the frontend talks to instead of calling many backend services directly. It aggregates data, hides service boundaries from the UI, and provides a single contract the frontend can rely on while the services behind it evolve. Composable stacks need it because a frontend that calls a dozen services directly becomes brittle and slow as soon as one of them changes.
Should we adopt the MACH Alliance principles?
Read them, treat them as a useful checklist, and adopt the ones that earn their keep for your business. The principles capture useful patterns (API-first, cloud-native, headless) that simplify integration and upgrade paths. They are not a prerequisite for a successful composable build, and treating them as a religious test will narrow your vendor list in ways that may not help.