For about ten years, choosing how to build an online store came with a loyalty test. You were either a monolith person or a headless person. The monolith camp wanted one platform that did everything. The headless camp wanted to tear the storefront off the commerce engine and assemble a stack from the best parts available. Conference talks framed it as old world against new. Vendor decks framed it as legacy debt against the future.
That argument is effectively over. Not because one side won, but because the people who actually run stores stopped treating it as a question of belief. The honest 2026 answer is not headless and it is not monolith. It is a pragmatic middle that most of the industry has quietly settled into, and understanding why it settled there will save you from buying an architecture that fights your business.
Origin: where the two camps came from
A monolithic commerce platform is a single, tightly integrated system. The product catalog, the cart, checkout, customer accounts, content, and the storefront all live in one codebase, built to work together out of the box. Magento, the early versions of Shopify, BigCommerce, and the enterprise suites all started this way. The appeal is obvious. You buy one thing, it works, and the vendor keeps the parts in sync. The cost is also obvious. Everything is coupled, so changing the storefront can mean wrestling the whole platform, and customization piles up as technical debt.
Headless commerce was the reaction. The idea is to decouple the frontend, the part the customer sees, from the backend commerce engine that holds product, pricing, and order data. The two talk through APIs. commercetools, which helped popularize the term, describes the split as separating the customer-facing layer from the engine that runs the data underneath. Once they are separate, you can rebuild the storefront in a modern framework, push the same catalog to a mobile app or a kiosk, and ship frontend changes without touching the engine.
Composable commerce took that further. Instead of just splitting front from back, it breaks the entire stack into modular pieces, catalog, search, checkout, promotions, and fulfillment, each chosen independently and connected by APIs. The rallying banner was MACH: microservices, API-first, cloud-native, headless. The MACH Alliance formed to promote it, and for several years MACH was treated as the obvious destination for any serious commerce operation. The pitch was freedom. Swap any component, never get locked in, assemble a stack of best-in-class tools.
The words are worth getting right, because vendors blur them. Headless is about one seam, frontend separated from backend. Composable is about many seams, the whole stack broken into swappable parts. A platform can be headless without being composable. The engine behind a decoupled storefront can still be a monolith. That distinction matters for what comes next.
Present: why pure headless overpromised
The promise of pure composability was a stack of Lego bricks. The reality, for a large number of merchants, was a box of parts with no instructions and a standing bill for an integration team.
The clearest signal of the mood shift came in March 2025, when VTEX, a publicly traded commerce platform, suspended its membership in the MACH Alliance. VTEX co-CEO Mariano Gomide de Faria did not phrase it gently. He said the pure best-of-breed approach had created as many problems as it solved, and described a path of hidden costs, operational burden, and unfulfilled promises. His argument was not that composability is wrong. It was that dogmatic, full decoupling had drifted away from what retailers actually need, which is revenue and working software, not architectural purity. A vendor inside the movement saying that out loud landed hard.
The numbers behind the complaint are real. Headless and composable builds cost far more than the marketing implied. One analysis of headless pricing puts mid-market implementation in the range of 75,000 to over 200,000 dollars, with monthly platform costs of several thousand dollars on top, and notes that roughly 62 percent of companies need outside help to implement at all. The harder problem is what arrives later. The same analysis points out that hidden costs tend to surface 6 to 24 months after launch, when integration friction and vendor coordination become clear, and that maintenance is where most teams underestimate badly. Practitioner accounts in the dossier behind this piece describe maintenance eating 60 to 70 percent of three-year cost. Industry guidance now openly says that for merchants under roughly 20 to 50 million dollars in online revenue, the complexity rarely pays for itself, and the brands that genuinely thrive on full headless tend to be well past 100 million.
Then there is the part nobody put on the slide. Decoupling the storefront breaks things that monoliths handled for free. SEO is the loudest example. A decoupled frontend can fracture internal linking, drop or duplicate metadata, and strip out the visual editing that let a marketer change a seasonal banner without filing an engineering ticket. Vendor lock-in does not vanish either. It moves. Instead of depending on one platform, you now depend on a web of contracts, integration choices, and the coupling between services you stitched together yourself. You traded a landlord for a mortgage, several contractors, and a building code you wrote.
None of this means headless was a mistake. For a global brand running many storefronts, or a business where half a second of page speed is worth real money, the control is worth the cost. It means pure headless was oversold as a default. It is a specific tool for a specific scale of problem, and most merchants are not that problem.
Present: the pragmatic middle that actually won
What replaced the argument is not a compromise nobody likes. It is a genuinely better idea, and it has a name the industry is converging on: packaged business capabilities, or PBCs.
A packaged business capability is a self-contained chunk of commerce functionality that delivers one outcome, search, or checkout, or promotions, or inventory, exposed through clean APIs. Elastic Path describes a PBC as everything you need to deliver a key business function without the unnecessary complexity. The trick is what sits inside one. A PBC is itself a bundle of pre-integrated microservices that behaves as a single unit. You get the modularity of composable, swap a capability when it stops serving you, without having to personally wire together every microservice underneath it.
This is pragmatic composability. Composable where flexibility actually pays, consolidated and pre-integrated where it does not. The vendor does the integration work that used to land on the merchant's engineering team. Gartner has effectively baked this into its definition of a modern platform. Its digital experience platform research predicts that by 2026 at least 70 percent of organizations will be mandated to acquire composable DXP technology rather than monolithic suites, up from 50 percent in 2023, and Gartner now treats a set of discrete, independently deployable PBCs as a baseline requirement for inclusion. Composable won the architecture argument. Pure, do-it-yourself MACH lost the implementation argument.
You can see the shift in what vendors ship. In March 2025, Shopify launched composable content accelerators, pre-built integrations with content platforms developed with partners, so enterprises get composable benefits without integrating each piece from scratch. Shopify's enterprise positioning is now explicit that you can build full-stack, headless, or composable on the same managed backend, rather than forcing one model. The MACH Alliance itself is evolving, moving toward end-user leadership and shifting its message away from purity. Even Algolia, a search vendor that profits when stacks decouple, now frames the choice as monolith for speed and simplicity, headless when the frontend is the real constraint, composable when business complexity genuinely justifies the operational overhead. The dogma is gone. The decision is back to being a decision.
Here is a frame you can use. Run your business through four questions before you touch architecture.
How big is the operation. Under roughly 20 to 50 million dollars in online revenue, a modern monolith or a lightly headless setup almost always wins on return. Past 100 million with real complexity, deeper composability starts to earn its keep.
How much engineering do you actually have. Composable assumes you can staff DevOps, platform engineering, and product ownership for the stack. The recurring regret is going headless without enough frontend developers to keep it alive. If you cannot name the team, you cannot run the architecture.
Where is the real constraint. If your storefront experience is genuinely held back by the platform's frontend, headless solves a problem you can point to. If it is not, decoupling adds cost and solves nothing.
How fast must you change. If you need to swap search or promotions often because that is where you compete, modular capabilities pay off. If your stack is stable, the integration tax is pure overhead.
Notice that none of these is a question about ideology. They are questions about your business. That is the whole resolution.
Future and impact: agents make the case for clean APIs, not for chaos
The argument did not just end. It is being reframed by what comes next, and the next thing is agentic commerce. Through 2025 and into 2026, the buying flow itself started moving off the storefront and into AI assistants. ChatGPT can complete a purchase inside the chat. Google and Shopify announced a shared protocol for agent-led checkout. The customer, increasingly, is a machine reading your catalog through an API.
It is tempting to read this as a final victory for pure headless. It is not. It is a victory for clean, well-structured APIs, which is a different thing. An agent does not care whether your stack is one box or twenty. It cares whether it can query your catalog, get accurate pricing, check real inventory, and complete a transaction without a human-shaped interface in the way. Analysis of agent-native commerce makes the point plainly: both a platform-integrated approach like Shopify's and a microservice-first approach like commercetools can serve agents well, because both expose the discrete, API-accessible capabilities an agent needs. What struggles is a genuinely monolithic legacy system with no clean API surface. Good API hygiene matters more than ever. Buying twenty loosely coupled services and integrating them yourself still does not.
This is exactly where packaged composability is well placed. A PBC is API-first by construction, so it is already agent-readable, and it is pre-integrated, so a merchant is not betting an agentic future on an internal team's ability to keep dozens of microservices in sync. The pragmatic middle turns out to be the safer bet for the agent era, not the riskier one.
The honest risks remain. Pre-integrated convenience is a softer form of lock-in, and a packaged capability is only as good as the vendor maintaining it. Pragmatic composability can become an excuse for not modernizing at all, a monolith with a nicer label. And agentic commerce raises a deeper question that no architecture answers: when a machine is the buyer, optimizing for price and availability and return policy, the storefront stops being the place you win the customer. Architecture decides whether an agent can read you. It does not decide whether the agent picks you.
For an enterprise weighing this, the useful work is not picking a camp. It is mapping where flexibility genuinely earns its cost, where consolidation is smarter, and which capabilities need to be clean and agent-readable first. That assessment, fit to a specific business rather than a vendor's preferred slide, is the kind of problem an implementation partner like Perform Digital is built to work through. The right architecture is the one that matches the business in front of you. After ten years of argument, that is the answer, and it was always going to be.
Council summary
This post argues that the headless versus monolith debate ended not with a winner but with a more useful answer: packaged business capabilities, a pragmatic middle that keeps the modularity of composable while letting the vendor absorb the integration cost. The council verified the load-bearing facts. VTEX, publicly traded on the NYSE, did suspend its MACH Alliance membership in March 2025 with co-CEO Mariano Gomide de Faria attacking the cost and operational burden of pure composability. The headless cost figures from netguru check out, Shopify's composable content accelerators launched in March 2025, and the Gartner prediction is real, though it is specifically about digital experience platforms, so the post now says so. The reader takeaway is concrete: stop choosing an architecture by ideology, run the four business questions, and treat clean APIs, not full decoupling, as the thing the agent era actually rewards.
Comments