Composable Commerce in the Real World: A Two-Week PoC That Changed the Conversation

Most composable commerce conversations stall at the same place: the client is intrigued, the architecture is sound, but the business case feels abstract. “Show me it works” is the thing they won’t say out loud but absolutely mean.

Last year I had the chance to actually show them.

The Setup

A client running a mature SAP Commerce implementation was evaluating whether to modernize toward a composable frontend. The platform worked. It had years of customizations layered on top of it. Nobody wanted to rip it out. But the frontend was showing its age — slow, hard to iterate, and far behind what their competitors were shipping.

The ask: could a modern composable frontend work on top of their existing backend without a full rewrite?

Two Weeks

I built a proof of concept using Alokai (formerly Vue Storefront) as the composable frontend layer, connected to the existing SAP Commerce APIs. The goal wasn’t feature parity — it was proof of concept on the key integration points: product catalog, cart, checkout, and account.

The constraints were real: no changes to the SAP Commerce backend, existing API contracts only, and it had to be demoed to stakeholders in two weeks.

Here’s what the two weeks actually looked like:

Week 1: Integration plumbing. Alokai’s SDK gives you a clean abstraction layer, but you still have to map your commerce API responses to its data shapes. SAP Commerce’s OCC APIs are verbose — a product response can have 40+ fields where you need 8. The mapping work is unglamorous but it’s where most PoCs die. I front-loaded it.

Week 2: Product listing, product detail, cart, and a stubbed checkout flow. Enough to walk through a real shopping journey in the demo.

What the PoC Proved

The demo landed. Not because it was polished — it wasn’t — but because it answered the actual question. The existing backend didn’t need to change. The team could ship frontend changes independently. The path from “PoC” to “production” was visible.

The client moved from evaluation to planning within a week of the demo.

What I’d Tell Anyone Doing This

Scope ruthlessly. A PoC that does five things at 60% is worse than one that does two things at 100%. Pick the highest-risk integration points and prove those. Everything else is distraction.

Make the constraints visible. The “no backend changes” constraint forced discipline that made the PoC more credible, not less. If you can show composability working within the existing system’s boundaries, the business case writes itself.

The demo is the deliverable. Not the code quality, not the architecture docs. A room of stakeholders who walk out saying “I see how this works” — that’s the output. Optimize for that.

The composable commerce conversation has shifted from “is it possible” to “what’s the migration path.” The PoC’s job is to make that shift happen. Two weeks is enough time to do it.