You went headless for a problem you didn't have

Headless and composable commerce got sold as the architecture of the future. For most mid-market brands, the real purchase was a permanent engineering payroll nobody put on the invoice.

Going headless means splitting the storefront from the commerce backend and building the front end yourself, so you control every pixel and lose the platform's guardrails. The pitch is speed and freedom from the theme. What rarely makes the pitch is the running cost: by the estimate of agencies that build them, a headless storefront runs two to three times the total cost of a native one over its first few years, and it does not maintain itself. Keeping it healthy takes at least one front-end engineer and one API or DevOps resource on hand for as long as the store exists. For a brand that went headless to fix problems its platform had already solved, that standing team is the entire price, and for most of them it turns into a hiring problem they never planned for.

Most of the reasons to leave have expired

Headless adoption made sense when the native platforms were limiting. International selling was painful, themes were rigid, the checkout was a black box, and developers wanted out. Those were real constraints, and brands left for real reasons.

Then the platforms closed the gaps. Shopify Markets handles multi-region selling, Online Store 2.0 opened up the theme, checkout extensibility and Functions let developers change the parts that used to be locked, and the agencies that built on those old limitations now describe merchants moving back toward a native setup. The specific pain that justified the rebuild in 2021 is mostly gone. What we keep seeing instead is rebuilds that happen anyway, carried by momentum more than a current read of what the store actually needs.

Performance is the reason that survives longest in the pitch and holds up least. A well-built theme on a modern CDN is already fast, often inside the range a headless rebuild is sold to reach, and the conversion lift that gets credited to headless usually comes from the optimization and experimentation work teams do around the migration. The architecture itself adds little. One headless builder's own report describes a 1.2-second speed gain lifting conversion by 8 percent, and credits the experiments around it more than the speed itself. You can run those experiments on a native stack. Plenty of brands paid for a replatform to reach a result a focused CRO sprint would have delivered on the store they already had.

The part you can't plan for

The two-to-three-times figure is real, but it is a number you can plan for. You approve a budget, you spend it, the project ships. The cost that actually does damage is the one that never ends and cannot be paused.

A headless storefront is a custom application, and a custom application needs people who know it. Lose the front-end engineer who built your Hydrogen store and what walks out the door is the only person who understands why checkout breaks on the busiest day of the year. One Shopify Plus agency puts it plainly: a brand running headless on two technical people is one resignation away from a business-continuity problem, in a talent pool thin enough that backfilling takes months. Most brands file that under maintenance. It is really a dependency, and they took it on without ever calling it one.

This was a hiring decision wearing an architecture costume

The clearest evidence that headless is oversold comes from the people selling it. A firm that builds headless storefronts for a living sets its own floor around $5M in revenue and a team of five or more engineers, and notes that headless developers command a 15 to 25 percent salary premium over standard full-stack hires. Read that as a staffing spec, because that is what it is. The architecture requires you to recruit and retain scarce, expensive specialists on an ongoing basis, and the vendor is telling you so in the cost breakdown.

The believers concede the rest. A longtime figure in the composable-commerce world reports projects that shut down when the ROI never arrived, and setups that ended up more rigid than the monolith they replaced, buried under integration work with no clear owner. The failure he describes is organizational more than technical. It comes down to whether you had the team to run the thing you bought.

When headless is actually the right call

Some brands should go headless, and it is worth saying so plainly rather than pretending the whole category is a mistake. If you really do sell across many regions and brands, or run product logic the native platform cannot express while serving content to several channels from one source, the flexibility earns its cost. The common thread in those cases is that the brand already has an engineering team, or is large enough to build and keep one. The MACH Alliance makes the same point from the inside: composable works best applied selectively, by how ready the organization is for it, more than by the technology. Those brands are real. Most of the brands that went headless in the last few years were not them.

Before you sign off on headless

Three questions settle most of the decision. Does the native platform genuinely fail your requirements, or does it just handle them a little less elegantly than you would like? Can you fund the engineers it takes to keep a custom storefront running for years, long after the build is done? Could you lose your most knowledgeable one next quarter and still ship? A no to any of them points the same way, toward staying native or fixing the real gap a cheaper way.

Price the team before you price the build. If you cannot name who maintains the storefront two years from now, and you cannot afford to lose them without a plan, you are not approving a technology, you are approving a payroll line that has to be recruited and retained in a tight market.

And when you do decide the specialists are worth it, hire for the specific seat, a front-end engineer who owns storefront performance or an integration engineer who owns the API layer, and skip the generic "headless developer" posting. The commitment is real either way. The brands that make headless work start from the team they can keep, and let the stack follow from that.