Headless
Composable Commerce Stack Architecture
Composable commerce architecture for DTC. We design the stack, pick the vendors, and land a reference implementation your team can actually operate.
What you get
Deliverables, not deliverable-ish.
Scoped plan
Written scope with success criteria, not a vague retainer.
Senior execution
The person scoping the work is the person doing the work.
Measurable output
Deliverables you can point at. Dashboards, flows, code, docs.
Clean handoff
Documentation and training so the work lives inside your team.
How we work
Our approach.
When composable makes sense and when it does not
Composable commerce became a buzzword around twenty twenty one. By twenty twenty three most brands who rushed into it had rediscovered a truth that the enterprise commerce world had known for a decade. Decoupling is not free. Every seam between services is a seam you have to integrate, monitor, and renew contracts against. A brand that moves from a single commerce platform to a stack of eight independent services has added significant operational complexity in exchange for flexibility. Whether that trade is worth it depends on the business.
Composable makes sense when one of three conditions is true. First, when the brand has reached a scale where no single commerce platform can deliver every capability at the quality bar the business requires. Second, when the brand has specific capabilities, usually around search, personalization, or localization, that justify best of breed vendors. Third, when the brand is explicitly optimizing for vendor replaceability because it has been burned by a monolithic platform before. If none of those are true, a well configured Shopify or Shopify Plus is almost always a better answer.
Composable does not make sense when the brand is under fifty million in revenue, does not have a front end engineering team of at least four people, or does not have a clearly articulated reason why a monolithic platform has failed. The operating overhead is real. The contract negotiation overhead is real. The integration failure modes are real. Brands who adopt composable without these foundations spend the next eighteen months discovering them the hard way.
Our approach
We run composable architecture as a five to eight week design engagement, optionally followed by a reference implementation that delivers a working thin slice of the stack.
- Step one, requirements and constraints. We document the commerce capabilities the business needs, the non negotiable vendor choices that already exist, and the team capacity available to operate the stack.
- Step two, reference architecture. We draft a reference architecture. Commerce engine, CMS, search, personalization, identity, payments, tax, shipping, analytics. Every service has a named vendor candidate and a named integration pattern.
- Step three, vendor selection. We run structured evaluations against the top two or three candidates for each service. Not a spreadsheet with ten columns. A focused evaluation against the three to five criteria that actually matter for your business.
- Step four, integration topology. We design the integration topology. Synchronous versus asynchronous, event bus versus direct API calls, identity flow, session management, and the failure modes at every seam.
- Step five, operating model. We design the team structure, the on call rotation, the change management process, and the vendor management cadence required to operate the stack.
- Step six, reference implementation. Optional. We build a thin slice of the stack end to end. Home, PDP, cart, checkout. This proves the integrations work and gives the internal team a reference codebase to extend.
What you get
- A reference architecture document that names every service, every vendor, and every integration pattern.
- Vendor selection outcomes with the evaluation rationale documented for each service.
- An integration topology diagram that shows synchronous versus asynchronous flows and the failure modes at each seam.
- An operating model document covering team structure, on call, change management, and vendor management.
- A three year total cost of ownership model.
- Optional. A reference implementation that proves the stack works end to end on a thin slice.
Timeline
The design engagement runs five to eight weeks. The optional reference implementation adds eight to twelve weeks depending on scope.
- Weeks one and two, requirements and constraints.
- Weeks three and four, reference architecture and vendor selection.
- Weeks five and six, integration topology and operating model.
- Weeks seven and eight, TCO modeling and handover.
- Weeks nine through twenty, optional reference implementation.
Mini case anatomy
A composite. A sixty million dollar beauty brand on a legacy commerce platform that was no longer hitting the business's capability requirements. International expansion was blocked. Search quality was poor. Personalization was non existent. The CTO had inherited the stack and wanted to replatform to a composable architecture.
The design engagement surfaced that the business actually needed best of breed capability in three areas. Commerce engine, search, and CMS. Everything else could be handled by the existing vendors or by capabilities bundled into the commerce engine. The reference architecture kept the stack at six services rather than the ten the initial brief had assumed. Each additional service had to justify its seat on the bus.
Vendor selection landed on a tier one commerce engine, a best of breed search vendor, and a structured content CMS. The integration topology used an event bus for cross service data flows and direct API calls for user facing reads. The operating model added one senior backend engineer and one platform engineer to the team, a cost the TCO model had already priced in.
The reference implementation shipped at week twenty. The thin slice covered home, PDP, cart, checkout, and the search integration. It ran in production against a small country launch so the team could stress test the stack before committing the main market. The country launch ran for sixteen weeks with no major incidents, which was the go ahead to plan the main market migration.
FAQs
Related reading. The headless development hub covers the full portfolio. For the front end implementation of a composable stack, see Next.js commerce. For Shopify specific headless patterns, see Hydrogen build. If the decision to go composable is still open, see platform strategy and headless Shopify versus Liquid. For CMS selection, see Contentful versus Sanity. For commerce engine comparisons, see Shopify versus BigCommerce and Shopify versus WooCommerce.
FAQ
Questions we hear most.
Other headless shopify development services services
Let's see if we're a fit.
15 minutes. We'll tell you whether this service fits where you are. If not, we'll name what does.
Book a 15-min call