How do you know when headless is enough?
-
A storefront redesign can turn into a much bigger architecture project once the discussion shifts to composable commerce. Before expanding the scope, I’d ask which backend capability actually needs replacing.
If the existing platform supports the catalog, pricing, and order workflows the business needs, separating the frontend may provide enough room to improve the customer experience. A new storefront won’t, however, remove restrictions in the platform’s promotion rules or fulfillment logic.
I work with Zoolatech, and our comparison of headless vs composable commerce covers that distinction.
One useful exercise would be to pick a single requirement—say, a promotion spanning online purchases and store pickup—and trace every system it touches. Where does the current setup prevent the change? What would replacing that component involve? Who would support it afterward?
That makes the architecture discussion much more concrete.
Has anyone here evaluated composable commerce and decided to keep most of their existing platform? What made that the better choice?