A composable build replaces the single platform that does everything with a set of services that each do one thing well, connected by APIs. The commerce engine handles catalog, payments, tax and checkout. Content lives in a headless CMS that marketing can publish from without a developer. Search runs as its own service. The storefront is an application that pulls from all of them.
The reason to do this is rarely the architecture itself. It is that something specific has stopped being possible on the platform you are on, and no amount of apps or workarounds is going to make it possible.
We start with the constraint, not the stack
The first question is not which platform. It is what the business cannot do today, described as something concrete. Marketing waits three weeks for a landing page. Pricing rules for wholesale customers cannot be expressed. Page speed on mobile is costing measurable conversion. Localization was bolted on and now every market change is a release.
Once the constraint is named, the architecture decision usually makes itself, and it is often smaller than expected. Most mid-market brands do not need every layer replaced. They need one or two layers moved and the rest left alone.
We scope to the problem, not the category
The version of composable that gets presented at conferences is the full rebuild, a year of delivery and a permanent platform team. That is a real architecture and it suits some businesses. It is also the most expensive shape composable can take and the one most likely to fail inside a company that cannot staff it afterwards.
The version we build more often keeps the commerce platform doing what it is good at, pulls out the layer that is actually blocking the business, and gives the storefront its own front end so the team can ship without waiting. That is still composable. It is just sized to the constraint.
We build the storefront as a real application
A headless storefront is software, not a theme. It gets a component library, a preview environment, automated builds and a rollback path. Every change gets a preview URL so stakeholders review the actual page rather than a screenshot. That operational side tends to change how a team works more than the performance gains do.
We plan for who owns it afterwards
The question we ask before quoting is who owns the stack after launch, by name rather than by department. A composable build with nobody accountable for it degrades faster than the platform it replaced. If the answer is that nobody internally will own it, that is worth knowing before the work starts, and it usually changes what we recommend.
We make the store readable by machines
Increasingly the thing arriving at a product page is not a person. AI agents research, compare and in some cases transact on a customer's behalf, and the protocols for that are being defined right now. A store built API first is already able to participate. A themed monolith with its checkout logic buried in templates is not. This is not the reason to go composable, but it is a reason the decision has become more urgent than it was two years ago.
