definition

What is composable commerce?

Composable commerce is an architecture pattern, not a product. It describes a commerce stack assembled from independent best-of-breed services, each chosen on its own merits and connected through APIs. The pattern is sometimes the right answer for a mid-market manufacturer, often overkill, and worth defining precisely before anyone signs a contract that promises it. This article gives you the working definition without the vendor marketing layer.

Plain definition with no vendor jargon

Composable commerce is a way of building a commerce stack from independent services rather than one all-in-one platform. Each major role (catalogue, cart, search, content, identity, payments, order management) runs as its own service, chosen on its own merits, and connected to the others through APIs. The stack is the set of choices and the contracts between them.

The premise is that a single vendor rarely has the best version of every role. A composable build assembles the version that fits each role and accepts the cost of integrating them. The promise is flexibility: services can be swapped later without rebuilding the whole stack. The cost is operational: every contract between services is a thing the team has to design, monitor, and version.

That is the working definition. Notice what it does not say. It does not say "modern". It does not say "future-proof". It does not say "best for B2B". It is a pattern with trade-offs, and the trade-offs are worth being explicit about before adoption.

MACH: microservices, API-first, cloud-native, headless

MACH is a well-known framing of composable, defined by the MACH Alliance, an industry group of vendors and integrators. The acronym names four principles a stack should follow to qualify as MACH: services should be small (Microservices), each should expose its capabilities through APIs (API-first), the runtime should be cloud-native rather than self-hosted, and the storefront should be Headless so the UI is independent of the commerce backend.

MACH is useful as a checklist for evaluating individual services. Treat it as a reference shape rather than a religious test. A successful composable build often blends MACH-compliant services with a couple of non-MACH components where the trade-off pays off, and the difference between a working stack and a dogmatic one is the willingness to make those calls case by case.

Composable versus suite

The honest opposite of composable is a suite: a single vendor's platform that ships the major roles together in one product. Shopify, BigCommerce, Shopware, SAP Commerce Cloud, and Salesforce Commerce Cloud are all suites, with differing levels of openness. Suites trade flexibility for cohesion: less integration work, fewer vendor relationships, faster initial build, and a single roadmap to track.

Suites are not less serious than composable. For a B2B manufacturer whose business logic fits the platform's model reasonably well, a suite ships sooner, costs less to run, and frees the team to invest engineering effort on the integration with the ERP and the customer-facing experience rather than on the contracts between services. The decision between suite and composable is a strategy decision, not a maturity decision.

The middle path most B2B manufacturers actually consider is suite-plus-augmentation: a native commerce platform with one or two best-of-breed services swapped in (commonly search and CMS) and the frontend decoupled for independent release. That hybrid pattern is covered in detail in the decoupled commerce article and in the when middleware is enough cluster.

Where the business logic lives in a composable stack

This is the question that decides whether composable works for a manufacturer. In a suite, business logic tends to live in the platform: pricing rules, promotion engines, account hierarchy, approval routing. In a composable stack, each service owns the logic that is native to its role, and a layer in front (often called a BFF, backend-for-frontend) holds the orchestration logic that the suite would otherwise own.

For a B2B manufacturer, most of the business logic that matters lives in the ERP regardless of architecture pattern. The ERP carries customer-specific pricing, contract terms, available-to-promise inventory, account hierarchies, and order state, because that is where the operational truth sits. Composable does not change that. It changes how many places talk to the ERP and how the orchestration between the ERP, the commerce engine, and the supporting services is shaped. The composable architecture on Acumatica article walks through one specific version of that orchestration.

The first three questions to ask before adopting composable

Before signing a composable build, manufacturers should be able to answer three questions honestly. First: which specific roles in your current stack actually need to be best-of-breed rather than good-enough, and why? If the answer is "search" and nothing else, the project is not a composable project. It is a search swap.

Second: who on your team will own the contracts between services in two years, after the agency or system integrator who built it has rotated off? Composable stacks fail more often from contract drift than from a single bad vendor choice, and the team that runs the stack on Monday morning is the team that has to hold the contracts current.

Third: what is the cost ceiling at which composable stops being worth it for this business? Composable typically costs two to four times what a suite costs over three years for a mid-market manufacturer. That number is sometimes worth paying. It is sometimes a quiet way to spend a lot of money to get a marginally better outcome. The true cost of composable article walks through the line items.

If those three questions have clear answers, the conversation about composable is productive. If they do not, the project has work to do before architecture is the right question. That work is what discovery and strategy is for.

Frequently Asked Questions

Next Step

Get the foundation right before you build.

For readers scoping a platform decision or wanting a full architecture recommendation.