Composable Commerce - Not just for Enterprise
"We’re too small for composable" is one of the most common sentences I hear from mid-sized retailers. What they usually mean is: "we’re too small for a multi-million euro programme with a new acronym". In this piece I share a demo storefront and some field experience to show how SMEs can use composable ideas to move faster without blowing up their entire stack.
A while ago I worked with a mid-sized retailer who could recite every benefit of composable commerce back to me, almost word for word. We spent weeks cutting scope. First a full re-platform, then a leaner composable MVP, then an even smaller “phase zero”. Every time we got closer to something they could sign off. It was too much money, too much risk, too many other priorities. In the end, they agreed that we pulled their content out of the monolith into a SaaS CMS. That step alone made a real difference. Publishing stopped being a pain and marketing finally had a tool they liked using. The core commerce engine stayed where it was. To support new use cases, their teams continued wiring custom services and scripts around the old platform. Over time, they accumulated tool proliferation, inconsistent data and a system that got harder to change.
This is the gap I keep running into. Composable commerce is sold as an enterprise story, but the pain of not being able to change fast enough is very much a mid-market problem.
If you look at how most composable commerce players position themselves, their deck is clear. They are trying to keep the growth curve in a market that is slowing down. They are aiming at global brands, complex org charts, seven-figure ACVs. The language is full of "enterprise-grade", "global expansion", "multi-brand", "multi-region" and so on. For a product or tech lead at a 50–300M brand, that’s an odd place to be. You feel the same pressure to adapt that global brands do, but you don’t have their budget, internal platform teams or appetite for multi-year change programmes. I am not surprised that composable oftentimes receives the same "postponed" stamp, which was put on every SAP-Migration project until S/4HANA caused a big enough pain. The irony is that composability, as an idea, is especially useful when you’re small. Not because you can out-spend anyone, but because you can’t. You need to steer through shifting customer expectations with a platform that doesn’t lock you into today’s answers.
When I built shop.cr0ss.org, I didn’t want another all-singing demo with twenty microservices and a diagram that looks like the map of the London Tube. I wanted a storefront that is small, sharp and honest and that I could use in conversations with exactly those mid-sized brands.
Under the hood it’s:
Next.js App Router on Vercel.
A commerce backend (in the repo it’s commercetools, but this could be Commerce Layer or another API-first tool, especially if you are a small business).
A headless CMS for content (Contentful in the demo).
A thin API façade inside the Next app that hides vendor quirks behind clean DTOs.
The interesting bit isn’t the choice of vendors, it’s the shape.
Pages like Home and PLPs are rendered from locale-aware APIs that don’t touch cookies at all. The cache keys are the things that actually matter for a catalogue page. They’re cached with unstable_cache and tagged by concern. When content or catalogue data changes, webhooks call back into the app and invalidate precisely those tags. The PDP takes the opposite stance. It runs at the Edge with no-store semantics for the actual product data. Price and stock are fetched fresh from the commerce API, with currency and country coming from query parameters instead of cookies. That combination keeps the experience fast where it can be, and honest where it must be. From a shopper’s perspective, none of this matters. What they feel the homepage is there, the category pages don’t hang and when they finally care about the exact size, price and availability, the product page answers without delay or error. From a retailer’s perspective, these are not "academic" decisions. Multiple studies over the last years have shown a clear link between web performance and conversion (even though it's a difficult time to quote cloud flare after their recent outages, but they put it correctly, when they said as page load times rise, conversion rates fall in a way you can measure). Google and Shopify have both reported that shaving as little as a second off mobile page load can materially boost conversions, in some cases by well over 20%. For an SME business these numbers decide whether you're profitable or not.
The biggest mistake is to treat composable as a binary decision where you either stay on the monolith forever or you do a full migration that touches half the company. In practice, most brands I talk to fall into a third category, they are already building composable islands around a monolith. The problem is that there isn’t a clear architectural spine, the result being that those islands end up connected with brittle point-to-point integrations. The demo project can be a starting point for this. A working example of the “front half” you can drop in front of almost any monolithic system. The important part is not that it uses commercetools and Contentful, but that the storefront doesn’t actually know much about either of them. If tomorrow you decide to plug in Akeneo as the PIM of record, that change is absorbed in the API layer, not sprayed across your entire front end. If you want to introduce a small search index you can slot it in as another provider without rewriting your whole app. This is design intent; the demo doesn’t implement every combination out of the box.
It’s easy to talk about caching purely in technical terms: ISR vs SSR, edge vs origin, tag-based invalidation, and so on. But for retailers, caching is really about Speed, Freshness, and Stability. The caching pattern in the demo storefront is opinionated on purpose. It is an example of a theoretical retail player with very specific requirements. Your business might be different, but you know your business best. That is where knowledge beats every architectural decision. No one on the marketing team needs to know what unstable_cache is. They just know that when they hit publish, the site reflects it within seconds without falling over. When someone from a mid-sized brand tells me we’re too small for composable, what they usually mean is we’re too small for a multi-year, multi-million euro project with a slide that says MACH on it. That part I agree with. What I don’t agree with is the conclusion that you should stay married to a platform that limits your ability to respond to your customers.
If you’re a product or tech lead at a mid-sized brand sitting on a creaky platform with big ambitions and limited budget, this is who I had in mind writing this. You don’t need a deck full of buzzwords and a seven-figure roadmap to benefit from composability. You need a few concrete steps in the right direction. If you’re in that "we know we need to move, but we feel too small for composable" space, I’d genuinely love to hear your story, especially the constraints you’re under. Those constraints are where the interesting, realistic architectures live.
This post was created as part of a larger campaign on composable commerce. Follow along for more post like this one.
