Composable commerce, explained honestly

What composable commerce actually is

Composable commerce is an architectural approach to ecommerce where each capability — commerce engine, search, CMS, payment, PIM, CRM, OMS — comes from a separate specialist vendor and connects to the rest of the stack through APIs. The merchant assembles these services into a working ecommerce system rather than buying a single monolithic platform that does everything.

The term was popularized by Gartner in 2020. Each capability in a composable stack is what Gartner calls a Packaged Business Capability, or PBC. The architecture is API-first by definition. Every service exposes its functionality through endpoints that other services can consume.

In practice composable commerce is more a philosophy than a fixed architecture. There is no certifying body that decides whether a given stack is composable. Most projects sit somewhere on a spectrum between monolithic and fully composable. Where a project lands on that spectrum is a delivery decision, not a binary classification.

For a side-by-side decision framework covering monolithic, headless, and composable in one view, see composable vs headless vs monolithic. This post focuses specifically on the composable model itself.

Composable vs MACH

MACH is the acronym most often confused with composable. It stands for Microservices, API-first, Cloud-native, and Headless, and was formalized by the MACH Alliance in 2020 as a set of architectural principles.

A MACH-compliant stack is composable by definition. The reverse is not true. A stack can be composable without meeting every MACH criterion. For example, a composable stack may include a service that is not strictly a microservice, or a vendor that does not run cloud-native infrastructure. MACH is a strict subset of composable. Composable is the broader category.

For most projects the distinction does not matter. Vendor marketing uses the terms interchangeably. The distinction does matter when an enterprise procurement team specifically requires MACH-compliant vendors, or when a vendor is using "composable" loosely to describe a stack that is really just headless with extras.

Packaged Business Capabilities (PBCs)

A PBC is the unit of composition in a composable stack. It is a self-contained service that delivers one business capability through an API. A composable stack assembles one PBC per capability. The common categories:

• Commerce engine: Norce, commercetools, Shopware, BigCommerce, Shopify’s Storefront API, Salesforce Commerce Cloud
• Search and product discovery: Algolia, Elastic, Hello Retail, Meilisearch, Coveo, Bloomreach Discovery
• Headless CMS: Storyblok, Contentful, Sanity, Strapi, Hygraph, Amplience
• Product Information Management (PIM): Akeneo, Plytix, Salsify, Pimcore
• Payment: Klarna, Stripe, Walley, Adyen, Vipps, MobilePay
• Checkout orchestration: Kustom, Ingrid, Walley Checkout
• Customer Data Platform (CDP) and CRM: Voyado, Klaviyo, Bloomreach Engagement, Tealium, Segment
• Reviews and UGC: Lipscore, Trustpilot, Yotpo, Bazaarvoice
• Order management (OMS): fluent commerce, Manhattan Active Omni, nShift
• Personalization and recommendations: Bloomreach, Dynamic Yield, Algolia Recommend

A real composable stack picks one PBC per capability and integrates them. The integration layer — typically a backend-for-frontend (BFF) — is where these services come together to feed the storefront.

Not every PBC needs to be specialist on day one. A Norce-based stack uses Norce's built-in catalog and product information by default. Adding Akeneo as a dedicated PIM is a later decision, made when the catalog complexity outgrows what Norce handles natively. The PBC list is a menu, not a checklist.

When composable commerce is the right choice

Composable is the right architecture when:

• Best-of-breed actually matters for the business. Search quality is a primary commercial differentiator. The PIM is a strategic asset. The CRM drives meaningful revenue. If these layers are genuinely strategic, paying for specialist vendors is worth it.
• Multiple channels share one product catalog. Web, mobile app, in-store kiosk, customer service tool, and marketplace integrations all read from the same commerce APIs. Composable architecture makes that pattern straightforward.
• The team can sustain the operational complexity. Either there is platform engineering capacity in-house, or there is a delivery partner that owns the integration layer post-launch.
• Vendor concentration is a real concern. Large enterprises and regulated industries often need to be able to swap any vendor without rebuilding. Composable enables that.

When composable commerce is the wrong choice

This is the section most vendor pages skip. Composable is the wrong choice when:

• The catalog is standard and the search requirements are simple. A monolithic platform's built-in search will be good enough. Paying for Algolia or Hello Retail on top adds cost without adding value.
• The team is small. Composable requires more vendor management, more integration maintenance, and more engineering oversight than monolithic. A team of three cannot run a ten-vendor stack effectively.
• Time-to-market dominates. A Shopify store with a quality theme can launch in weeks. A composable stack with several new vendors takes months. If the merchant needs to ship now, composable is the wrong starting point.
• The current platform is working. Replatforming from a functional monolithic platform to composable for architectural reasons alone rarely pays back. The migration cost is high and the customer-facing improvement is often invisible.

Composable adoption is often driven by architectural fashion rather than business need. Vendor marketing claims of 80% faster feature shipping or 30% faster time to market are real for some projects and irrelevant for others. The question to ask is what specific capability is blocked by the current architecture, not whether composable is generally better.

Where most projects actually land

Most production projects described as composable are not fully composable. They are commerce stacks with two or three composable-pattern PBCs layered on top of an otherwise integrated platform. The most common pattern:

• One commerce backend (Norce, Shopware, commercetools) owning products, pricing, cart, checkout, and orders.
• A dedicated headless CMS (Storyblok, Contentful) replacing the platform's built-in content tools.
• A specialist search vendor (Algolia, Hello Retail) replacing the platform's built-in search.
• A modern headless frontend built on Vue, Nuxt, React, or Next.js.
• Everything else — PIM, OMS, CRM, payment — still relying on the commerce platform's default or first-party integration.

That pattern delivers most of the practical benefit of composable (specialist search, specialist CMS, flexible storefront) without the full overhead of running a fully composable stack. Adding more PBCs over time is straightforward when one of them becomes a real bottleneck.

How Frntkey fits into a composable stack

Frntkey is a frontend-as-a-service for the storefront layer of a composable or headless commerce stack. It connects to Norce or Shopware as the commerce backend. It ships with Storyblok bundled as the CMS. It plugs into Meilisearch or Hello Retail for search, Klarna or Walley for payment, Voyado for CRM, Lipscore for reviews — each a distinct PBC.

The architecture is composable-ready, not full composable from day one. Most projects launch with the bundled stack and add additional PBCs over time when specific capabilities justify the integration cost. That incremental path is the most common production pattern across the merchants Frntkey serves.

For projects that need fully composable from launch — enterprise PIM, separate OMS, specialist CDP, custom checkout orchestration — the Frntkey storefront supports that too. The constraint is delivery scope, not architecture.