Composable Commerce: What It Actually Means for Mid-Market Brands

Composable commerce is the architectural philosophy that you should assemble your ecommerce stack from best-of-breed components rather than buying a monolithic platform. Pick the best CMS, the best search provider, the best checkout, the best PIM, wire them together via APIs, and you have a system perfectly tailored to your needs.

In theory, it's elegant. In practice, I've seen it work well for large enterprises with dedicated platform teams, and cause significant pain for mid-market brands that adopted it based on a persuasive conference talk.

What composable actually involves

A composable stack might look like this: Shopify as the commerce engine, Contentful or Sanity for content management, Algolia for search, a custom Next.js frontend, Akeneo for product information, and a middleware layer connecting everything.

Each component is independently deployable, independently scalable, and independently replaceable. If Algolia's search isn't working for you, swap it for Typesense. If Contentful's pricing climbs too high, move to Strapi.

That's the promise. The reality is that every component needs configuring, integrating, monitoring, and maintaining. You're not buying a platform — you're building one, component by component.

The hidden cost: integration maintenance

Each connection between components is a custom integration — and every one of them is susceptible to the patterns I describe in five integration mistakes ecommerce brands keep making. Content from Sanity needs pushing to the frontend. Product data from Akeneo needs syncing to Shopify and to the frontend. Search indexes need populating from product data. Cart state needs managing across the frontend and Shopify's backend.

Every one of these connections needs error handling, monitoring, and regular attention as APIs evolve. When Shopify ships a new API version, you update one integration. When Contentful changes their API, you update another. When your frontend framework releases a major version, the entire rendering layer needs updating.

I've worked with a mid-market brand — around £8M in revenue — that adopted a composable stack. They had seven integration points between components. Maintaining those integrations consumed roughly 40% of their monthly development budget. The remaining 60% went to actual feature work, which was less than they'd have achieved on a monolithic platform.

When it genuinely makes sense

Composable works when you have the team to support it. Specifically:

You have at least two full-time developers who understand the entire stack and can debug issues across component boundaries. If your development resource is a single freelancer or a small agency on retainer, composable creates a dependency risk that's hard to manage.

Your requirements are genuinely unusual. If your content model is so complex that Shopify's native CMS and metaobjects can't handle it, a dedicated CMS component is justified. If your search requirements include visual search, AI recommendations, and advanced merchandising rules, a specialist search provider earns its place.

You're doing enough volume to justify the investment. The operational overhead of a composable stack is roughly fixed regardless of revenue. For a brand doing £50M, that overhead is a small percentage of the technology budget. For a brand doing £3M, it's disproportionate.

The pragmatic alternative

For most mid-market brands, the better approach is what I call "composable-adjacent." Use Shopify as the platform. Extend it with targeted integrations where Shopify's native capability falls short. Don't replace Shopify's CMS — extend it with metaobjects. Don't replace Shopify's search unless you've outgrown it. Don't build a custom frontend unless themes can't do what you need.

This gives you 80% of the flexibility of a composable stack at 30% of the complexity. And critically, it gives you a single platform vendor — Shopify — who handles hosting, security, checkout, and payments. Those are the parts you want someone else to worry about.

When a specific component genuinely isn't meeting your needs — search is the most common example — add a best-of-breed tool for that specific function. Algolia or Klevu integrated with a Shopify theme is composable in spirit without being composable in architecture.

Questions to ask before going composable

Before adopting a composable architecture, answer honestly:

Who will maintain the integration layer when your current developer moves on? How will you monitor seven different services and the connections between them? What happens when two components have conflicting upgrade timelines? Do you have the budget for the operational overhead on top of the development work?

If the answers are uncertain, composable probably isn't right for you today. Build on a solid platform, integrate where necessary, and evolve toward composable only when a monolithic approach is demonstrably holding you back.

The brands I've seen succeed with composable are the ones that grew into it gradually — not the ones that started there. I cover the broader principles behind this in what I look for in a good ecommerce tech stack.