Headless commerce pays off at the two ends of the market and is over-engineering in the middle. The deciding factor is not your revenue but how much your store needs to change and who changes it.
The Shopify ecosystem has a well-funded argument for the other side: headless platform vendors need you to believe architecture is a maturity signal, and the bigger you get, the more you should decouple. That argument fits the vendors' incentives. It does not always fit your business.
We build native-first architectures for most of our clients and headless-on-Shopify at the high end, but only when it's warranted. So this is not an anti-headless position. It is a fit position. More often than not, the headless projects that reach us now run the other way: migrating a brand back to native off a build that was over-engineered, or sold on headless it never needed. The difference matters because the cost of getting the call wrong in the middle is real: a merchandising team filing dev tickets for changes they used to make themselves, and velocity lost in a stack that was supposed to unlock it.
The barbell, drawn
Picture a U-shaped curve. The y-axis is headless viability: how much the architecture returns relative to what it costs to operate. The x-axis is operational complexity: how much your store changes, how often, who changes it, and whether your organization has the in-house checks and balances to absorb the cost and risk of that change. Size tracks it loosely, but only as a proxy.
At the low end: a small, agile brand that moves fast and carries little process. Few bodies, few hard rules about what the site can and cannot do, less legal and brand scrutiny, and a high appetite for risk. Often this is a design-forward brand with a small catalog and a vision a native theme cannot express, run by a team comfortable with code. Here headless is viable. AI-assisted builders have made it cheap to build, and the organization absorbs change without a committee, so the operating overhead stays manageable. A design-forward native theme still does the job at lower total cost, so viable is not the same as optimal.
At the high end: a brand or platform whose requirements are genuinely architectural. A storefront experience that theming cannot express, or one commerce backend serving many surfaces at once, or several distinct brands sharing a single catalog and loyalty layer. And the organization to carry it: enough people, a real in-house engineering team to own the frontend permanently, and the process maturity to run it safely. Here headless earns its keep, because the problem is genuinely architectural and the company is built to absorb it.
The messy middle is the gap between, and it covers most mid-market DTC. These brands have taken on the process of a larger company, more bodies, more SOPs, more approvals, more legal and brand scrutiny, so risk tolerance drops and change already moves slower. What they do not have yet is the in-house engineering depth, or the checks and balances, to run a custom frontend at full operating cost. Too much process to stay nimble like an SMB, not enough scale to be resourced like an enterprise. Size tracks this loosely, call it $5M to $100M, but the number is only a proxy for where a brand sits. It is the band where we do most of our work, and where headless is most often over-engineering.
Why the middle keeps buying headless anyway
The case for going headless usually starts with ambition, not architecture. A peak-season site that slowed down and cost revenue. A redesign that hit the ceiling of what a theme could do. A competitor's storefront that looks nothing like Shopify.
Three forces push mid-market brands toward headless. First, the maturity-signal narrative: headless reads as what serious brands do, and a competitor's composable-commerce announcement lands as a critique of everyone still on a native theme. Second, vendor incentives: headless platform vendors and headless-first agencies have a financial reason to frame it as the answer before they understand the question. Third, peer pressure: the conference slides feature Next.js storefronts and call it best practice.
None of those forces are wrong about what headless can do. They are consistently wrong about what it costs once it is live. That is the part that does not make it into the slides, and the operating cost is not the only one hiding there: custom JavaScript storefronts are disproportionately the ones that end up invisible to AI shopping agents, which is its own reason to keep the middle native.
"But AI makes headless cheap now."
I thought we were past headless for most brands. Then low-lift builders like Lovable, with their Shopify integrations, put it back on the table: a custom frontend is cheap enough to stand up now that headless is squarely available to any brand willing to accept the risk that comes with it. So the objection is worth taking seriously, because it is half right.
AI coding tools and frontend builders have genuinely compressed the cost to build a headless storefront. What used to take an engineering team a full quarter to build can now be prototyped in weeks by a lean team. That compression is real, and it has shifted the calculus at the low end of the barbell, where build cost was always the main barrier.
The distinction that matters is this: AI collapses the cost to build a headless frontend, not the cost to operate one.
For a mid-market DTC brand, the operating cost is where the math breaks down. Every new promotional collection, every seasonal merchandising update, every A/B test on a product page is a task that someone with frontend access has to pick up. On a native Shopify store, a skilled merchandiser handles that without touching code. On a headless store, every change either lands in a dev ticket or waits.
That tax does not feel steep at first. A few extra developer hours per month is manageable. At scale, it is the thing that quietly kills merchandising velocity. A brand that used to ship five promotional pushes a month ships three, because two are waiting on dev bandwidth. The headless architecture that was supposed to enable better commerce becomes the thing slowing it down.
AI-builder tools work at the low end of the barbell, where the store is stable and the build was always the hard part. In the middle, the build has always been manageable. The operating cost is the problem, and AI does not change that.
Where the data lives, and who approves the change
A headless frontend still has to keep its content and structured data somewhere, and that decision is where a lot of these builds quietly go wrong. The disciplined answer on Shopify is to keep Shopify as the source of truth and model custom content as metaobjects, not as a sprawl of metafields pressed into service as content types. We see the metafield-sprawl version constantly on large stores, and it is expensive to run and worse to migrate. The over-built answer is bolting a separate CMS onto a mid-market store that never needed one, which doubles the systems the team has to operate.
AI builders sharpen the problem, because the data model becomes a decision the tool makes for you. Spin a frontend up with Lovable or a similar builder and it will often map poorly to Shopify or stand up its own storage on the side, and now your product content lives in two places. The deeper issue is governance: who approves what ships? On a fast-moving small brand, edits and deploys ride on trust that the AI says it works, with no review gate. Give several people that access with no staging and no approval step, and changes reach production ungoverned.
That is a real risk, and it follows the same barbell. A small, agile, risk-tolerant brand can absorb ungoverned change, because the stakes are low and speed is worth more than a review process. A brand with brand guidelines, legal review, and a customer base it cannot afford to surprise cannot. An enterprise absorbs the same risk a different way, with staging, code review, and a data model someone owns. The middle gets the exposure without the SMB's speed or the enterprise's controls.
The real axis is complexity, not size
Revenue is a shorthand that misleads. What actually decides the answer is how much the storefront has to move and who stands between marketing intent and execution. The diagnostic question, which is also the right one to ask any agency selling you headless: how much does your store need to change, and who changes it?
Two brands at the same GMV can land at opposite ends of the curve.
Sketch one. A design-forward lifestyle brand, $25M GMV, two major product lines, a six-month seasonal cycle. The marketing team updates hero copy twice a year. The brand has a clear visual identity that a native theme's section structure cannot express. A design-forward native theme gets close; if the visual requirements are genuinely unique, a headless approach is viable. The store does not change enough for the operating cost to compound, and there is no merchandising team losing hours to dev tickets.
Sketch two. A $25M wellness brand, 200-plus SKUs, a subscription program, and a marketing team running six to eight campaigns a month, each needing collection, content, and homepage changes. This storefront has to move at the speed of the marketing calendar, not developer availability. Headless does not make it faster here; it puts a bottleneck between marketing intent and execution that the team spends years working around.
Same revenue. Opposite architectural answer. The axis is not GMV.
Where headless does earn it
At the high end of the barbell, headless is the right call. The brands that belong there have a recognizable profile.
The clearest signal is a storefront experience that Shopify's theming genuinely cannot express: app-like interactivity, a complex product configurator, or personalization that lives at the component level. The bar is higher than most teams assume, because Online Store 2.0 theming, sections, and metaobjects already deliver most of what gets called "we need headless."
The second signal is scope beyond a single storefront: one commerce backend feeding several surfaces at once, a web store plus a native app, in-store screens, or partner experiences, all reading from the Storefront API; or several distinct brands sharing one catalog, inventory, and loyalty layer; or a catalog large enough that discovery needs custom logic beyond native search and filtering.
The third signal is a real in-house engineering team. Headless requires someone to own the frontend permanently, not a retainer for episodic work. A brand that relies entirely on an agency for frontend changes has transferred the operating cost to a slower, more expensive loop. The brands where headless consistently works have engineers on staff whose job includes the storefront layer.
A caution on what does not belong on that list: checkout. Even a headless storefront on Shopify hands the shopper back to Shopify's checkout, so "we need a custom checkout" is an argument for checkout extensibility on Plus, not for going headless. Multi-region pricing is native through Markets, and B2B is native too. The moment a headless pitch rests on checkout or B2B, the reasoning is wrong.
We build headless-on-Shopify at this end of the market and advise in both directions. The architecture is the answer when the problem is genuinely architectural, not when it signals seriousness. When a brand at this end asks whether headless is right, the answer is usually yes. When a brand in the middle asks the same question, the answer is almost always no, because the problem they are trying to solve is operational, not architectural, and headless makes operational problems harder.
If you already went headless and regret it
Two types of brands arrive at this conversation.
The first went headless on Shopify, usually with Hydrogen, and is feeling the operating cost. Collections that used to take an hour now take a sprint. The merchandising team is filing tickets for tasks they used to handle themselves, and developer hours are going to storefront maintenance instead of features. For these brands, the path forward is usually a replatforming back to a native theme, scoped to capture what the headless build was supposed to accomplish aesthetically while returning the marketing team's independence. The migration work starts with understanding what the headless architecture was actually solving, and whether native Shopify solves it at lower operating cost.
The second came off a non-Shopify headless stack that required a full engineering team to run at any level. Replatforming to Shopify Plus native is not a downgrade. For most of these brands it is a consolidation that cuts operating cost and gives the marketing team a platform they can actually run, because the capabilities that drove their headless decision five years ago are often native today.
The one question to ask before you decide
Before any architecture decision, ask this: how much does your store need to change, and who changes it?
If the honest answer is "rarely, and a developer is available when it does," headless is viable. If the answer is "constantly, and right now it is the marketing team," native Shopify will outperform headless at your scale, regardless of what the architecture slides say.
This is not a replacement for a proper scoping conversation. But it is the right first filter, and it is the question we ask on every inbound where architecture is on the table. The brands that benefit most from headless already know their answer; the ones that struggle discover it six months after launch.
We are a Shopify Premier Partner. Our senior team advises on native and headless and builds both. Fifteen years on Shopify. Based in New York, NY.
If you are deciding on architecture, preparing a replatforming, or trying to understand what is slowing down a headless build you already own, we scope both directions. Get in touch. Let's Talk Shop(ify).