What headless commerce actually buys you (and when it doesn't)

Headless commerce, decoupling the storefront from the commerce backend, gets pitched as a strict upgrade over a traditional platform theme. It isn't. It's a real architectural tradeoff that solves specific problems well and adds real cost and complexity for stores that don't have those problems in the first place.

We've inherited more than one headless project from another agency where the honest answer, once we dug into the original reasoning, was that nobody had actually made this tradeoff deliberately, it had simply been assumed to be the modern, correct choice without weighing it against what the store actually needed.

A headless build gives full control over the front-end experience, unconstrained by a platform's theme templating limits, which matters when a brand needs a genuinely custom storefront experience, tight integration with a non-standard checkout flow, or the same product catalog powering multiple front ends (a website, a native app, an in-store kiosk) from one backend. It also tends to be faster, since a custom front end built with performance in mind isn't carrying a theme's accumulated weight.

The multi-channel case is the one that most clearly justifies the investment in our experience: a retailer with a website, a native app, and an in-store kiosk all needing the same live catalog data benefits enormously from one backend feeding all three, versus maintaining that catalog logic separately in each.

Every feature a themed Shopify or WooCommerce store gets for free from an app or built-in functionality, a headless build has to implement custom: cart logic, checkout flow, search, filtering. That's real development time and real ongoing maintenance, and it means the total cost of ownership is meaningfully higher, not just the upfront build cost.

We've had clients underestimate this specifically around checkout, assuming a custom checkout flow is a relatively small piece of work, when in practice payment processing, tax calculation, shipping rate integration, and fraud prevention are each genuine sub-projects that a themed platform simply includes by default.

For a store doing under roughly $2 million in annual revenue with fairly standard catalog and checkout needs, a well-built themed Shopify store almost always wins on total cost and time to market. Above that, especially with custom catalog logic, multi-channel needs, or a front-end experience that's become a genuine competitive differentiator, headless starts to pay for itself. This isn't a hard rule, but it's where we start the conversation.

We share this threshold with clients directly, including the reasoning behind it, rather than presenting it as an unexplained rule of thumb, since a founder who understands why the line sits where it does can tell us if their specific situation has a factor that should move it.

Shopify's own newer front-end tooling, and similar options from other platforms, now offer much more customization within the themed model than a few years ago, closing part of the gap that used to only be solvable by going fully headless. We increasingly recommend pushing a themed platform as far as it'll genuinely go before recommending a full headless rebuild, since the maintenance savings compound every year the store keeps running.

This middle path has quietly become our default first recommendation for clients who arrive already convinced they need headless, and in a meaningful share of those conversations, once we actually map their real requirements against what the themed platform's newer tooling can do, the case for going fully headless weakens considerably.

Is there a specific front-end experience or integration that the platform's theme model genuinely cannot deliver, not just delivers less elegantly? If yes, headless is probably worth it. If the honest answer is "it would just look a bit more custom," the themed platform is almost always the better use of the budget.

We put this question in writing in every proposal comparing the two options, along with the client's specific answer, so the reasoning behind the recommendation is traceable months later if anyone on the client's team ever needs to revisit why the decision was made.

A themed store can often be maintained by a single ops-minded person comfortable installing apps and editing theme settings. A headless storefront needs an actual developer on call, or a retainer with an agency, for anything beyond content changes, since custom-built cart logic, checkout flows, and search don't have a plugin marketplace to lean on when something needs adjusting. This staffing reality gets underestimated as often as the build cost itself.

We spell this out explicitly during scoping, including a realistic monthly hour estimate for ongoing maintenance, because a client who's budgeted for the build but not for the team needed to run it afterward ends up either under-maintaining a system that needs real attention or scrambling to hire once something breaks in production.

A furniture retailer came to us already committed to a headless rebuild, convinced by an earlier vendor pitch. Once we mapped their actual requirements, standard catalog, standard checkout, one sales channel, against the cost of custom-building cart and checkout logic from scratch, the numbers didn't support it. We recommended a heavily customized Shopify build instead, which shipped in eight weeks at roughly a third of the original headless quote, with no functionality the business actually needed left out.

Eighteen months later, that decision has held up: the business added two new product lines and a loyalty program, both handled through existing Shopify apps rather than custom development, at a fraction of what the equivalent custom features would have cost on a headless stack. Not every story goes this direction, but this one is a useful reminder that the more exciting-sounding architecture isn't automatically the better business decision.

We've since started asking every client who arrives already convinced they need headless to walk us through where they first heard the term, since it's frequently a conference talk or a competitor's stack rather than a specific limitation they'd hit in their own business. That's not a knock on the architecture itself, it's a reminder that a real requirement and a borrowed opinion can feel identical from the inside until someone asks the question directly.