Composable commerce is a way of building an online business from separate, replaceable components, each covering one business capability such as the product catalog, pricing, cart and checkout, search, content or order management. The components talk to each other through APIs. Instead of one platform that does everything, you pick a component for each job and can replace one without rebuilding the rest. Shopify describes it as selecting and integrating "best-in-breed technologies" connected via APIs (Shopify).
Shopify credits the analyst firm Gartner with coining the term. The components are called packaged business capabilities (PBCs), and the architecture usually follows the MACH principles. For most mid-market merchants the practical answer is not "go fully composable" but "make the stack modular where it hurts": keep a commerce platform at the core and swap in specialist components one at a time. In every version, product data needs exactly one owner, and that is the job a PIM does.
Packaged business capabilities: one business job per component
A packaged business capability is, in Shopify's words, a software component that represents "a particular business function", such as checkout or search. Commerce Layer describes a composable stack as one built around PBCs that are "individually developed, deployed, and managed, connected through APIs" (Commerce Layer).
In a typical commerce stack, the PBCs and the data each one owns look like this:
- Product information: products, attributes, variants, translations, images and category assignments.
- Pricing and promotions: price lists per market or customer group, discounts and coupon rules.
- Cart and checkout: baskets, shipping options and the tax calculation at checkout.
- Payments: payment methods, authorizations and refunds.
- Search and merchandising: the search index, synonyms, ranking and boosting rules.
- Content: landing pages, banners, buying guides and other editorial pages.
- Order management: orders, stock allocation across warehouses, fulfillment and returns.
- Customer accounts: logins, addresses, B2B company accounts and loyalty balances.
A PBC is not the same thing as a microservice. Checkout is a PBC because it delivers a complete business outcome; address validation inside checkout is a microservice. One PBC can contain several microservices, and one vendor can sell several PBCs.
MACH, letter by letter
MACH is the label most composable vendors use for the technical principles behind their products. It was promoted by the MACH Alliance, launched in June 2020 by commercetools, Contentstack, EPAM Systems and Valtech, and stands for "Microservices based, API-first, Cloud-native SaaS and Headless" (Gilbane).
- M for microservices: each capability is built as a suite of small services, each running in its own process and talking over lightweight APIs, the definition Martin Fowler and James Lewis gave in 2014 (Martin Fowler). See our microservices architecture entry for how that applies to commerce.
- A for API-first: every function is available through a documented API before any user interface is built on top of it.
- C for cloud-native SaaS: the vendor hosts, scales and updates the service; you consume it rather than install it.
- H for headless: no built-in storefront; the front end is a separate application.
MACH describes components; composable describes how you assemble them. A stack can be composable without every part being MACH. Plenty of composable setups keep an on-premise ERP or a legacy warehouse system and wrap it with an API. Our MACH architecture entry covers the certification side.
What swapping one component at a time buys you
The case for composable commerce rests on a few concrete gains. They are real, but each one depends on the integration work described further down.
- Replacing a weak capability without a replatform. If on-site search fails on technical part numbers, you change the search component and leave checkout, orders and the storefront alone.
- A specialist per job. A B2B seller can add a pricing engine that handles price lists per dealer, which many all-in-one platforms only cover through apps.
- Separate release cycles. The front-end team can ship a new product page without waiting for a back-end release, and the other way round.
- Scaling where the load is. With cloud-native SaaS components, the vendor scales search or the storefront for a sale peak without you sizing servers for the whole stack.
Headless vs composable commerce, and the hybrid middle
We covered the front-end split in what is headless commerce. The short distinction: headless moves one boundary, between storefront and back end. Composable moves many, inside the back end. In practice, merchants end up in one of four setups:
- All-in-one platform: one vendor runs storefront, catalog, checkout and orders; extra features come from the platform's app store.
- Headless on one platform: a custom front end on top of a single commerce back end.
- Hybrid or modular: a commerce platform stays the core, and one or two capabilities, often search, content or product information, come from specialist tools.
- Fully composable: the back end itself is assembled from PBCs by different vendors, with a headless front end and an integration layer in between.
The hybrid middle is common even among large companies. In a survey Shopify ran with IDC of over 1,000 enterprises, 45% had "a composable front end with a full-stack back end" (Shopify). The survey covers enterprises, not mid-market merchants, who usually have fewer developers to run a fully composable back end.
Who owns which data in a composable stack
The design decision that matters most is not which vendors you pick but which system is the source of record for each kind of data. Take a mid-market outdoor gear brand with 4,000 SKUs, web stores in three countries, a B2B portal for dealers and two marketplaces:
Source of record per data type in a composable stack
| Product content (titles, descriptions, attributes, translations, images, categories) | PIM | Read by the storefront, search, marketplaces, feeds, the B2B portal and the CMS |
|---|---|---|
| Cost and base prices | ERP | |
| Channel prices and promotions | Pricing engine or commerce platform | |
| Stock | ERP or warehouse system | Published to channels through order management |
| Orders | Commerce engine | Handed to order management for fulfillment |
| Editorial pages | CMS | References products by SKU instead of copying their text |
| Search index | Search service | Fed by product content from the PIM plus price and stock |
| Customer accounts | Commerce engine or a dedicated identity service |
The rule behind the table: every field is written in one place and read everywhere else. When the PIM and the commerce platform can both edit product titles, or the CMS keeps its own copy of a product description, the versions drift apart and nobody knows which one is right. SKU and GTIN become the join keys between systems, so they have to be unique and stable.
When composable commerce fits a mid-market merchant
Shopify's own guidance is that composable is "probably not right for you" unless you are digitally mature, with an experienced engineering team and complex delivery needs. For a mid-market merchant, these signals help decide.
Signals that favor composable components
- One capability of your current platform blocks revenue and no app fixes it, for example B2B price lists per dealer or search across 40,000 technical SKUs.
- You sell through several front ends (web stores per country, a B2B portal, kiosks) that must share products, prices and stock.
- You have developers in-house or an agency on a long-term contract, and someone who owns the integration layer.
- Your product data model is already clean: typed attributes, real variants, one SKU per sellable item.
Signals that favor a platform with a few specialist tools
- Your team changes the store mostly through admin screens and apps, without a developer on call.
- Your growth problems are traffic, assortment or product content, not platform limits.
- You run one or two stores in a few languages, and the platform covers checkout, payments and orders well.
- Your catalog still has gaps such as missing attributes, supplier copy and inconsistent units. Splitting systems would spread those gaps across more places.
Many merchants in the second group still benefit from one composable move: taking product information out of the store admin and into a PIM that feeds every channel. That gives most of the data benefits without rebuilding checkout.
The running costs a composable business case tends to leave out
License fees per component are easy to list. These costs are not, and they last as long as the stack does:
- Integration build and upkeep: every connection between components is code someone has to write, test and update when either side changes its API.
- Monitoring across vendors: when an order fails, you need to trace it through storefront, checkout, payments and order management, each with its own logs.
- API version changes: vendors deprecate API versions on their schedule, not yours.
- Data mapping: each component has its own model for products, prices and customers, and someone maintains the mapping between them.
- Vendor management: more contracts, more renewals, more security reviews.
- Skills: composable needs people who understand the whole system, not just one tool. Shopify notes that with several vendors, maintenance and update costs can pile up quickly.
The PIM as the product capability every other component reads
In a composable stack, product information is a capability of its own. The storefront, search, marketplaces, feeds, the B2B portal and the CMS all read from it. That raises the bar for what the PIM has to provide:
- A clear data model: product families, typed attributes with units, variants and relationships, so every consumer reads the same structure.
- Validation before publishing: completeness and format rules per channel, so search and feeds do not index half-finished products.
- APIs and events: an API for reads and writes, and change events or webhooks so search indexes and storefront caches update when a product changes. Our event-driven architecture entry explains the pattern.
- Channel-specific outputs: the same product with a short title for a marketplace, a long description for the web store and a different attribute name for a feed.
- Localization: translated text and localized attribute values for every market.
- Stable identifiers: SKU and GTIN kept unique, since every other system joins on them.
A PIM built for this role is often called a headless PIM: it has an editing interface for the content team, but its output is consumed by API rather than shown in a storefront of its own.
Getting this capability in place is usually the first step of a composable roadmap, not the last, because every later component depends on it. Our PIM implementation plan covers that project step by step.
Moving toward composable one capability at a time
A big-bang replatform to a fully composable stack is the riskiest path. A phased route works better for mid-market teams:
A phased route to a composable stack
- 1
Phase 1
Map capabilities to pain
List the PBCs from the section above and score each one: does the current platform handle it well, poorly or not at all?
- 2
Phase 2
Fix the product data model and move product content into a PIM
Every later component reads product data, so it pays to have one clean source first.
- 3
Phase 3
Replace the capability with the clearest pain
For many stores that is search or content; for B2B sellers it is often pricing or customer accounts.
- 4
Phase 4
Go headless when channels require it
For example when a second country store or a dealer portal needs its own front end.
- 5
Phase 5
Add order management or a pricing engine as complexity grows
Typically when stock sits in several warehouses or prices vary per customer.
- 6
Phase 6
Switch off what you replaced
Leaving the old feature running beside the new component recreates the two-sources problem.
Five ways composable projects turn into a distributed monolith
- Components that share a database. If search and checkout read the same tables, you cannot change or replace one without breaking the other.
- Long chains of synchronous calls. When the product page waits on search, which waits on pricing, which waits on stock, one slow service takes the whole page down.
- Two systems editing the same field. Product titles edited in both the PIM and the commerce admin drift apart within weeks.
- Glue code nobody owns. Integrations written for the launch and never assigned to a team break at the first API change.
- Buying components before defining data ownership. Without a source of record per field, each new tool adds another copy of the catalog.
Plugging WISEPIM into a hybrid commerce stack
WISEPIM covers the product information capability. It imports your catalog, fills missing descriptions, attributes, translations and categories with AI, checks completeness with Quality Guard, and pushes the result through platform sync to Shopify, WooCommerce, Magento 2, Lightspeed eCom, CCV Shop, Kaufland, Google Merchant Center and other connected channels. With opt-in auto-sync, a saved product reaches those channels about 30 seconds later; scheduled imports and exports run through automations with an hourly, daily, weekly or monthly trigger. Teams that already run Akeneo can connect it as a source.
If you are weighing a modular stack, start with the product capability: import your catalog on the free plan (up to 100 products) and see which fields every other component would need before you choose a single vendor.
