I remember the exact meeting where we first pitched headless to a large retail client. The slides were beautiful. Decoupled frontend. Independent deployments. Your developers, finally free from the monolith, shipping at whatever velocity they wanted. The CTO was nodding. The VP of Engineering looked like someone had just handed him a get-out-of-jail card.
That was 2019. Fast forward to today, and that same team has 14 microservices, three different frontend frameworks in production, a custom middleware layer that two people understand, and a deployment pipeline so fragile that nobody ships on Fridays. Their backlog is longer than it was before they went headless.
They aren’t an outlier. They’re the norm.
The promise of headless commerce was real, by the way. I still believe in the architectural principles. Decoupling your presentation layer from your commerce engine is the right idea. But somewhere between the conference keynotes and actual implementation, “headless” mutated into “composable,” and composable mutated into “you’re now responsible for building and maintaining an entire technology platform from scratch.” Nobody put that on the slide deck.
Let me be specific about what goes wrong, because the devil here is genuinely in the details.
When you adopt a composable architecture, you’re signing up for a set of responsibilities that didn’t exist in a monolithic platform. Integration contracts between services. API versioning across vendors. Authentication flows that span multiple systems. Caching strategies that have to account for data freshness across four or five different sources. Monitoring and observability across a distributed system where a single page load might hit eight APIs.
That’s not theoretical overhead. That’s real engineering work, and it lands squarely on your team. Not on the vendor that sold you the CMS. Not on the agency that built the initial implementation. On your internal engineering org, forever, for as long as you run the architecture.
And here’s the part that really stings: most of this complexity is invisible to leadership. It doesn’t show up on a roadmap. It shows up as slower sprint velocities, as “infrastructure work” that keeps getting prioritized over feature delivery, as the vague sense that things should be moving faster than they are. The architecture is technically working. It’s just consuming all of your team’s oxygen to keep it that way.
I talked to an engineering lead at a mid-market fashion brand last quarter. They went composable in 2022, chose a headless CMS, a separate search provider, a standalone personalization engine, a dedicated OMS, and wired it all together with a custom Next.js frontend. Eighteen months later, roughly 40% of their frontend engineering capacity goes to maintaining integrations. Not building features. Not improving conversion. Maintaining the glue code that holds their “flexible” architecture together.
The composable commerce TCO conversation almost never accounts for this. Vendors quote their individual licensing costs. Nobody quotes the cost of making six vendors play nicely together in production, under load, across regions, while your business team needs to launch a campaign by Tuesday.
Here’s where I’ll be honest about something our industry doesn’t say enough: headless absolutely can improve developer productivity. But only for a specific slice of the work.
If your developers are building novel, differentiated features (a custom product configurator, a complex B2B pricing engine, a deeply integrated loyalty experience), headless gives them the freedom to use the right tools and frameworks. That’s genuine value.
The problem is that 70% of what enterprise ecommerce teams actually need to ship isn’t novel or differentiated. It’s landing pages. Campaign templates. A/B tests. Personalization rules. Content updates. Promotional banners. The operational stuff that drives revenue but doesn’t require (and shouldn’t require) a React developer and a sprint cycle.
In a monolithic platform, this operational work was slow because of platform limitations. In a composable architecture, this same operational work is slow because you’ve replaced platform limitations with architectural complexity. Different constraint, same outcome: business teams waiting on engineering.
I find this genuinely ironic. We sold headless as the escape from developer dependency, and in many cases, we’ve deepened it. Your marketing team used to be limited by Salesforce Commerce Cloud’s page designer. Now they’re limited by your custom component library that needs a pull request to modify. We swapped one cage for a nicer-looking one.
Your marketing team doesn’t care whether they’re blocked by Salesforce Commerce Cloud’s rigid templating system or by your custom Next.js build pipeline. Blocked is blocked.
I’ve spent enough time auditing composable implementations to see the same cost patterns emerge repeatedly. And they almost always catch teams by surprise.
Integration maintenance. Every vendor connection is a liability. APIs change. Rate limits shift. Authentication tokens expire. A single vendor update can cascade failures across your frontend. Teams typically underestimate integration maintenance by 3x to 5x.
Talent concentration risk. Your custom composable architecture is, by definition, unique. The knowledge of how it works lives in a small number of heads. When those people leave (and in this market, they will leave), you’re rebuilding institutional knowledge from scratch. I’ve seen this paralyze teams for six months or longer.
Performance optimization complexity. In a monolith, performance tuning is centralized. In a composable stack, a slow page might involve debugging latency across five different services, three CDN configurations, and a middleware layer. The mean time to resolution goes up. Sometimes dramatically.
Upgrade coordination. When you’re running six vendors, you’re managing six different upgrade cycles, six different deprecation timelines, and the interactions between all of them. A breaking change in your search provider’s API can block an upgrade to your CMS.
Testing and experimentation overhead. In a unified platform, A/B testing is constrained but at least centralized. In a composable stack, testing across independently deployed services means coordinating feature flags, managing state consistency, and ensuring that variant A of your CMS content plays nicely with variant B of your personalization engine. Many teams just stop testing because the operational cost exceeds the insight value. That’s a failure mode nobody talks about at composable conferences.
Add it up and the composable commerce TCO for a mid-market brand often runs 30% to 60% higher than projected. For enterprise, the variance can be even wider. The technology is usually cheaper. The human cost of operating it is not.
I want to be clear: I’m not making the case for returning to monolithic platforms. That ship has sailed, and for good reason. The architectural principles behind headless are sound. The decoupling of concerns is correct.
What went wrong is that the industry conflated architectural flexibility with operational simplicity. They’re not the same thing. You can have a beautifully composable architecture that’s operationally miserable to work with every day.
The actual fix is something I think about as an execution layer: a platform that sits on top of your composable stack and absorbs the complexity that your business teams shouldn’t have to deal with. Not by replacing your commerce engine or your CMS. By providing a unified surface where marketers, merchandisers, and growth teams can build, test, and launch experiences without filing Jira tickets.
This is what Fastr Frontend was designed to do. It connects to your existing commerce platform (Shopify, Salesforce, BigCommerce, whatever you’re running) and gives business teams the ability to create and modify frontend experiences visually. No code. No deployment pipeline. No sprint capacity required.
The result isn’t fewer developers. It’s developers working on the right things.
ONI Global is a good example. They’re a multi-brand enterprise running a composable stack. Before Fastr, their publishing workflow was exactly the bottleneck I described earlier: business teams generated requests, those requests entered a development queue, and weeks passed before anything went live. The composable architecture gave their engineering team flexibility for complex builds, but the day-to-day publishing work was still stuck in the same pipeline.
After implementing Fastr Frontend as their execution layer, ONI cut publishing time by 50% and reduced costs by 65%. Not by rearchitecting their composable stack. By giving their business teams a way to bypass the engineering queue for the work that never belonged there in the first place.
Similar story with Lulu Guinness. They achieved 30% cost savings and significantly reduced their dependency on external agencies. The pattern is consistent: when you give non-technical teams the tools to execute independently, the entire organization moves faster. Engineering capacity isn’t the bottleneck anymore because you’ve removed 60% to 70% of the work that was clogging it.
The debate between composable and monolithic is a false binary, and I think we’ve wasted years on it. The real question is: who bears the complexity?
In a monolith, the platform absorbs complexity but limits flexibility. In a composable stack, you get flexibility but absorb all the complexity yourself. Neither answer is satisfying on its own.
A unified experience platform (which is really what Fastr Workspace is, though I realize that’s a mouthful) takes a different approach. Keep your composable backend. Keep your best-of-breed vendors. But put a layer on top that absorbs the operational complexity of building and optimizing customer experiences. Your architecture stays flexible. Your operations become simple.
Think of it this way: you don’t need to replace your composable commerce frontend. You need to replace the workflow around it. The code-deploy-test-repeat cycle that turns a simple content change into a two-week project.
I’ve been building commerce technology for a long time, and I’ve noticed something about productivity conversations. They almost always focus on the wrong metric. Teams ask, “How do we get more output from engineering?” when the better question is, “How much of what we’re asking engineering to do is actually engineering work?”
In most enterprise ecommerce organizations, the answer is uncomfortable. Half the development backlog (sometimes more) consists of tasks that a capable business user could handle with the right tools. Content updates. Layout changes. Campaign launches. Test configurations. This work doesn’t require a computer science degree. It requires a platform that doesn’t force every change through a code pipeline.
Headless gave us the right architectural foundation. Composable gave us the right vendor strategy. What neither gave us was an operational model that works for the humans who actually run the business day to day.
The question isn’t whether composable commerce was the right direction. It was. The question is whether your team should be spending their time maintaining the architecture or using it to grow revenue. If the answer is the former, you don’t need more developers. You need a better execution layer.