A $6M apparel brand came to us eighteen months into a headless build that was supposed to take four months. Their original agency had pitched Hydrogen as the “next-level move” their competitors weren’t making yet. By the time we got the call, they had burned through $140,000 in development fees, their marketing team couldn’t update a banner without filing a dev ticket, and their Lighthouse score was sitting at 54 — worse than the Liquid theme they’d left behind. The checkout still converted. The business didn’t grow.
We’ve watched this play out more than a dozen times in the last two years. Not because headless is a bad technology. It isn’t. But because agencies sell it, founders buy it, and the pattern of who actually needs it gets ignored in the pitch.
TL;DR: Headless Shopify Plus is the right architecture for a small slice of $1M–$10M brands — those with genuine frontend complexity, multiple sales channels, or a dedicated engineering team. For most brands in that range, it costs $80K–$200K to build and months of runway to maintain, with no meaningful conversion lift over a well-built Liquid store. The pattern we’ve seen across 1,000+ Shopify projects: headless solves a developer problem, not a founder problem.
The Pitch That Moves Founders
The headless pitch is good. We’ll give it that. Faster pages, total design freedom, your developers working in React, marketing and engineering no longer “stepping on each other.” If you’re running a $5M brand and your agency drops that deck in front of you, it’s compelling. Speed is real. Flexibility is real. The part that gets quietly glossed over is the cost structure and the team you need to make it work long-term.
Here’s what the pitch rarely covers: headless doesn’t just change how your storefront is built. It changes who can touch it. Your merchandising team, which used to drag-and-drop banners in the Shopify theme editor, now needs to route every content change through a developer or a headless CMS they’ve never used. Your apps — the review widget, the loyalty program, the upsell tool — all need to be rebuilt or replaced on the new frontend. And the agency that built the headless store is often the only team who can maintain it.
That dependency is expensive. And it’s the part that never appears in the proposal.
What the Real Cost Looks Like
A production headless build on Shopify Plus runs $80,000–$200,000 for a standard DTC brand. Complex B2B builds or multi-region storefronts push higher. That’s the build cost. Then there’s ongoing maintenance, which is not optional — headless frontends require active developer attention that Liquid themes simply don’t. Add a headless CMS license (Contentful, Storyblok, Sanity) if your marketing team needs to manage content without engineering, and you’re adding $500–$1,500 a month before you’ve shipped a single product update.
For a brand doing $5M in annual revenue, that’s a meaningful share of margin tied to an architectural decision that was framed as “the next level.” The ROI math has to work. And for many brands in the $1M–$10M range, it simply doesn’t — not at current build costs. One honest assessment puts the payback window for a mid-market headless build at 12–18 months under favorable conditions. Below $5M in revenue, the same capital directed at conversion rate work or acquisition typically returns three to five times more.
We’re not saying don’t do it. We’re saying know what you’re buying.
The Brands That Actually Need It
We’ve done builds where headless was clearly the right call. They share characteristics that are worth naming precisely, because “complex needs” — the phrase most headless guides use — tells you nothing useful.
The real signals: your Lighthouse score is consistently below 60 on a properly tuned Liquid theme (not a bloated one — a tuned one), and you have conversion rate data showing speed is the actual lever. You’re running a true multi-channel operation — website, mobile app, in-store kiosk, international storefronts — where one Shopify backend needs to power multiple distinct frontends simultaneously. Your frontend UX requirements are genuinely outside what Liquid and Online Store 2.0 can handle: complex product configurators, real-time inventory visualization, buyer portals with custom pricing logic tied to an ERP. Or you have a dedicated engineering team that will own and maintain the frontend after launch — meaning this isn’t an agency-dependency play, it’s an internal capability decision.
If three or four of those are true, headless may be the correct architecture. If one is true — say, your developers prefer React — that’s a hiring decision, not a platform migration. Hire a Liquid developer. The talent pool is larger and meaningfully less expensive than a full headless frontend team.
The Pattern We Keep Seeing
Across the brands that came to us post-headless-mistake, the pattern is consistent. The decision was made in a sales conversation, not a technical audit. The agency doing the pitching was also the agency doing the building. The founders were shown speed benchmarks from a demo environment, not from production stores with real app stacks running. And the marketing team’s dependency on engineering post-launch was never modeled in the proposal.
That last point is where the real cost accumulates. A $6M brand doesn’t just lose $140,000 on a build gone sideways. It loses eighteen months of merchandising velocity — the seasonal campaigns that didn’t ship cleanly, the PDP tests that sat in a dev queue, the product launches that required coordinating three engineers instead of one content manager. That operational drag compounds quietly, and it never shows up on the original agency invoice.
For context: a well-optimized Liquid-based Shopify Plus store, built properly from the start, delivers 90–95% of the performance benefit headless promises — at a fraction of the build cost and with a team your marketers can actually work inside. That’s not a compromise. That’s the right tool for the job.
The Hybrid Option Nobody Talks About
There is a middle path that most headless conversations skip entirely. Hybrid architecture — keeping Liquid for standard commerce pages and going headless only on the parts that genuinely need it. A custom B2B account portal. A product configurator with 100+ variants. A sales rep dashboard with ERP-driven pricing. Everything else stays in the theme editor where your marketing team can move without a dev ticket.
Lower build cost. Lower monthly maintenance. Marketing keeps operating independently. Engineering gets to solve the actual complex problem. For mid-market brands tempted by full headless but unable to justify the total cost of ownership, hybrid is often the move that makes commercial sense without burning the runway on an architecture decision the store didn’t need end-to-end.
It’s the option that rarely appears in the pitch deck. It’s also the option we recommend most often when a founder comes to us asking about going headless.
The Objection: “But Headless Is Where the Ecosystem Is Going”
Some agencies will tell you that headless is the direction of the market and any brand not moving toward it is falling behind. This is a pitch, not a position. Most successful Shopify Plus brands you could name today — brands doing $10M, $50M, $100M+ in annual revenue — are not headless. They’re running well-built, well-maintained Liquid stores on Shopify Plus, and they’re growing without an engineering team dedicated to frontend maintenance.
The argument that gets made is about agentic commerce and AI-referred traffic — the idea that API-first architecture makes your store more discoverable by AI shopping interfaces. There’s something real there. AI-referred traffic to Shopify merchants is a growing channel, and a clean, fast storefront matters for conversion when that traffic lands. But a well-optimized Shopify Plus Liquid store with proper structured data handles that exposure just fine. You don’t need to rebuild your frontend architecture to be indexed by an AI shopping interface. You need fast load times, clean schema markup, and a product catalog that isn’t buried under app bloat. That’s a performance and SEO problem, not an architecture problem — and it’s far cheaper to solve.
The “headless is the future” framing also ignores how much ground native Shopify Plus has recovered. Features that required custom headless builds two or three years ago — B2B catalogs with company-specific pricing, multi-region storefronts, complex discount logic — are now available natively. Brands that went headless in 2022 to solve those problems are now maintaining expensive custom infrastructure for use cases the platform handles out of the box.
What to Do About It Monday Morning
If you’re being pitched on headless, or you’re actively considering it, here’s how we’d pressure-test the decision before you commit:
- Run a Lighthouse audit on your current store with a clear-eyed read. If your score is above 65 on a properly maintained Liquid theme, speed is not the problem headless is solving. Identify what the actual problem is before choosing the architecture designed to solve it.
- Model the full cost of ownership, not just the build quote. Take the agency’s proposal and add: ongoing developer retainer for maintenance, headless CMS license if your marketing team needs content access, and the internal time cost of routing content changes through engineering. Run that number against your current annual revenue and ask what the conversion lift would need to be to justify it.
- Ask who owns the frontend after launch. If the answer is “the agency that built it,” you’ve just locked yourself into a dependency that will cost you for as long as the store runs. That’s a vendor relationship decision disguised as a technology decision.
- Check whether your actual problem is a native Shopify Plus feature now. B2B catalogs, Shopify Markets for multi-region, Checkout Extensibility for custom checkout logic, Shopify Functions for discount and shipping rules — if what you’re trying to build is on that list, you likely don’t need headless to get there. Our Shopify Plus checkout customization guide covers how much is possible without touching your frontend architecture.
- Consider the hybrid path before the full build. Identify the one or two pages or features that genuinely require headless-level flexibility. Build those as custom components while leaving the rest of the store in Liquid. You solve the real problem without rebuilding the entire commerce experience.
If after that analysis headless still makes sense — if the signals are real, the team is in place, and the use case is genuinely beyond what Liquid can handle — then build it with confidence. We’ve done those builds. They’re worth it when the conditions are right. The job is making sure the conditions are actually right before the invoice arrives.
The Founder’s Reality
Most founders who come to us post-headless-mistake say the same thing: the pitch made sense at the time. It sounded like the serious, grown-up infrastructure decision a $5M brand should be making. And no one in the room — not the agency, not the dev team, not the CTO they’d just hired — was asking the question that mattered: does this brand have the operating model to maintain what we’re about to build?
Architecture doesn’t grow a business. Revenue velocity grows a business. The stores we’ve watched scale from $2M to $8M in two years weren’t headless. They were design-led, conversion-focused, and operationally tight — built on Shopify Plus foundations that let their marketing teams move fast without waiting on a developer. If you want to see what that looks like in practice, the Metro School Uniforms case study is a good place to start: 138.7% organic growth, built on a Shopify Plus store that a non-technical team could operate and update without routing every change through engineering. No headless required.
The right architecture is the one your team can actually run. That’s not a compromise. That’s the lesson.
If you’re in the middle of a headless evaluation and want a straight read on whether it’s the right call for your specific store, here’s what that conversation looks like with an agency that’s done both.
FAQ
How much does a headless Shopify Plus build actually cost in 2026?
A standard headless build on Shopify Plus runs $80,000–$200,000 for a DTC brand, with complex B2B or multi-region builds pushing higher. That’s the build cost only. Ongoing maintenance, headless CMS licensing, and developer retainers add $5,000–$17,000+ per month to the operating cost. Most proposals show the build; few model the full monthly run-rate after launch.
When does headless Shopify actually make sense for a $1M–$10M brand?
Headless makes clear commercial sense when you need a single Shopify backend powering multiple distinct frontends (website, app, kiosk), your frontend UX requirements are genuinely outside what Liquid and Online Store 2.0 can deliver, or you have an internal engineering team that will own and maintain the frontend after the agency hands off. If none of those conditions are true, a well-built Liquid store on Shopify Plus delivers the same performance outcome at a fraction of the cost and maintenance burden.
Will going headless help my store rank better in AI search and get more AI-referred traffic?
A clean, fast storefront with proper structured data performs well in AI-referred traffic channels regardless of whether it’s headless or Liquid-based. The underlying requirements — fast load times, schema markup, a well-organized catalog — are achievable on a properly optimized Liquid store. Rebuilding your frontend architecture to capture AI search traffic is solving the wrong problem; focus on Core Web Vitals and structured data first.
What’s the hybrid headless approach and is it a real option?
Hybrid architecture keeps your standard commerce pages in Liquid — where your marketing team can operate independently — and builds only the specific features that genuinely require headless-level flexibility (a custom B2B portal, a product configurator, a sales rep dashboard) as custom components. It’s a lower build cost, lower maintenance overhead, and keeps non-technical team members out of the dev queue. For mid-market brands that have one or two genuinely complex use cases but don’t need a full frontend rebuild, it’s often the most commercially sensible path.
