Headless Commerce, Honestly.
Most brands shouldn't go headless. That's an odd thing to read on an agency site that builds headless sites among other things — but it's the honest place to start. The reliable research from inside the industry suggests roughly three out of four brands that arrive wanting a headless build are better served by a well-built traditional Shopify, WooCommerce, or Magento store. And roughly four out of ten mid-market headless projects fail within their first year.
If that's where you're sat already, write to us at hello@wewbd.com — we're e-commerce platform agnostic (Shopify, WooCommerce, Magento, headless — whatever fits the brand is what we'll build), and we'd rather build you the right thing than the trendiest thing. You can skip the rest. For everyone else, here's the longer answer — what headless actually is, what came before, what you pair it with, when it's right, when it isn't, and what life looks like on the other side.
What headless commerce actually is
Headless commerce is what you get when you split a website into two pieces.
One piece is the front of the shop — what your customer sees. The product pages, the imagery, the typography, the homepage, the checkout flow's visual layer. Designers and writers can change this piece without touching anything in the back.
The other piece is the back of the shop — the catalogue, the inventory, the orders, the payments, the customer accounts. It runs on a commerce engine (Shopify, BigCommerce, commercetools, or a custom one) and it does the heavy lifting.
The two halves talk to each other through APIs. The front asks the back for a product; the back replies. The front sends an order; the back processes it.
That's the entire idea. Two halves, connected by an API. Decoupled, in the jargon.
What came before
Before headless, your shop was one thing. The front and the back were married. Shopify themes, Magento layouts, WooCommerce templates — these are all monolithic systems, which is the unkind word for "the design and the database know each other intimately."
Monolithic isn't a bad idea. It's actually a great idea for most businesses. The platform takes care of everything. You pay a fee. You get a working shop. You can swap themes. You can add apps. You can sell.
The reason monolithic platforms get a bad reputation is that the brands using them eventually run into the platform's ceiling. The theme system can only flex so far. The checkout looks like Shopify's checkout. The page builder can only do what the page builder allows. If your brand's idea of the shop doesn't fit inside what the platform was designed for, you either compromise or you replatform. That's the moment the headless conversation usually starts.
What you pair headless with
A headless front needs four things, roughly.
A frontend framework. This is the code that builds the customer-facing site. Almost everyone in the headless ecosystem in 2026 uses Next.js — a React framework that handles routing, server-side rendering, image optimisation, and the various performance trade-offs that used to require a senior engineer to think through. Next is what we build on. Shopify's own Hydrogen framework is another option, also React-based, but more tightly coupled to Shopify.
A commerce engine. Where the products, orders, and payments live. Shopify is the most common choice — the Storefront API is mature and well-documented. BigCommerce, commercetools, and Saleor are the other names that come up. For some brands the right answer is to build the commerce engine yourself — we'll get to one of those below.
A content management system. Where the editorial content lives — homepage modules, journal posts, marketing pages. We use Sanity. Contentful and Storyblok are the other names you'll see in the wild.
A host. Where the site actually runs. Vercel (who make Next.js) is the default. Netlify and Cloudflare are the alternatives.
Plug those four together with API calls and you have a headless site.
Why headless became a thing
A few things came together around 2020 that pushed headless from a niche pattern into a default conversation.
Frontend frameworks got dramatically better. Next.js in particular went from a developer toy to a production-grade platform. Vercel made deploying it as easy as connecting a GitHub repo.
Headless CMSs matured. Sanity, Contentful, Storyblok and friends gave content editors interfaces that didn't feel like they were maintained by someone who hated their job.
Shopify, BigCommerce, and the other commerce platforms opened their APIs. The commerce engine could now be reached from outside the platform's built-in storefront.
And brands got better at noticing the difference between a good site and a templated site. The aesthetic ceiling on monolithic platforms started feeling lower.
What headless gives you
When the decision goes the right way, headless does things a templated site genuinely cannot. We've spent a lot of words on the caveats already — it's worth being equally direct about why the architecture is worth caring about at all.
Speed. A well-built headless site, served from a global edge network, is faster than almost any templated equivalent. Pages that used to take three seconds to load now take three hundred milliseconds. Conversion rates respond to that in measurable ways. The architecture isn't magic — a badly built headless site can be slower than a good Shopify theme — but the ceiling is much higher.
A content team that can actually move at the pace of the marketing calendar. A good headless CMS (Sanity, Contentful, Storyblok) puts editorial control directly into your team's hands — homepage modules, journal posts, banner campaigns, full marketing pages. No tickets to engineering. No waiting for a deploy. Edit, hit publish, it's live. This bit alone has paid back the build for more than one of our clients.
Going global without paying tax to a platform. Multi-language, multi-currency, multi-region routing — handled in the framework, on the edge, the way you'd build it if you were starting from scratch. Templated platforms make this work; headless lets it feel native.
An app, not a theme. This is the part most headless-explainer pieces undersell. When you go headless, your site becomes a piece of software your business owns. If you have a business problem — an unusual flow, a custom integration, a new way of selling — you can build something to fix it. You're free in a way you simply aren't on a templated platform. (You do, of course, still have to build the thing.) For brands whose business logic is genuinely distinctive, that freedom is the entire point.
Modularity. The site is built out of pieces that can be swapped without rebuilding the whole. Change your commerce engine in eighteen months? Possible. Add a B2B portal that shares the same product catalogue? Possible. Spin up a campaign micro-site on the same stack? Possible. This is the long-game argument and it's a genuine one when the brand's roadmap calls for it.
Ownership. A templated site is rented space — you're operating inside someone else's architecture, their decisions, their roadmap, their pricing changes. A headless site is yours. The code is yours. The data model is yours. The shape of it is yours. For brands that think of their site as a product, not a tool, that ownership matters.
When headless actually makes sense
We say yes to a headless build for a brand when at least one of these is true.
The brand's identity genuinely cannot live inside a template. This sounds obvious, but it's a high bar. Most brands' identities can live inside a thoughtfully customised Shopify theme. The brands that genuinely can't are usually ones whose product is unusual, whose story is non-linear, or whose audience expects an experience that doesn't look like the rest of the internet.
The brand sells across more than one channel and needs to share a single inventory. A web shop plus a wholesale portal plus a mobile app plus an in-store POS. The commerce engine sits in the middle; the various fronts all pull from it.
The brand can justify the ongoing engineering cost — though that cost has moved. The published industry numbers (two to eight thousand a month for a maintained headless site) were written before this generation of AI development tools landed. Claude Code, Cursor, and the rest of the current toolkit compress experienced engineers' time meaningfully — sometimes dramatically — and the running cost of a well-built headless site today is lower than it was a year and a half ago. A site doing a million a year can now sometimes carry the cost where two million was the floor not long back.
Worth being honest about what AI tools are and aren't, since the headless conversation runs into the AI conversation now whether anyone wants it to. The tools are tools in the toolbox, not the toolbox itself. They compress an experienced developer's time. They do not replace the architecture decisions, the taste, the code review, the ten-year-old-bug intuition, or the senior judgment that keeps a production site upright when something breaks at 3am. If anyone tells you a headless site can be "AI-built" end-to-end without humans in the loop, walk away. The compression is real; the substitution isn't.
The brand wants the commerce engine to be its own. Most builds use Shopify as the engine. Some — including the one we built for Pegoretti — replace the engine entirely with a bespoke commerce flow. This is rare and we'll cover why it makes sense in a moment.
If none of those is true, we say no. Honestly, we say no more often than yes.
When headless is the wrong answer
The clearest signs you shouldn't go headless.
Your annual revenue is under one million. The maths doesn't work. A good Shopify theme will get you further per pound spent.
You don't have a developer on retainer. Headless sites need ongoing engineering work. Adding a homepage banner becomes a code change. Launching a holiday campaign means commits and deploys. If you don't have someone for that — either in-house or an agency you trust — you'll regret going headless within six months.
Your current site's problems are creative, not technical. New design, new copy, new photography, new layout, new product structure — all of these can usually be solved on Shopify without changing platforms. We've talked plenty of brands out of replatforming and into doing the creative work properly on the system they already have.
The headless pitch you're hearing leads with "scale" and "future-proofing." Those are fine ideas but they're often used to justify a build that won't pay for itself for years. If your agency can't tell you specifically what going headless unlocks for your business in the next twelve months, they're selling architecture for its own sake.
What life on the other side looks like
The thing most "should you go headless?" articles don't tell you is what it's actually like to run a headless site once it's live.
Editorial content lives in a CMS like Sanity. Your team logs in, edits a homepage block, hits publish. Within thirty seconds it's live. This bit is genuinely lovely.
Product data and orders stay in the commerce engine. Adding a product, updating stock, fulfilling an order — all unchanged from a monolithic platform. Your operations team won't notice the difference.
Anything new that touches the frontend layout, the checkout flow, the URL structure, the SEO behaviour, or the integration with a new tool requires a developer. This is the bit brands underestimate. On Shopify you can usually install an app. On a headless build you usually can't — at least not in the same way.
Performance can be excellent, but it's not automatic. A badly built headless site is slower than a well-built Shopify site. The architecture only helps if the build is good.
Analytics requires more thought. Shopify's standard tracking just works. On a headless build you wire it up. Done well it's fine; done badly it leaks data and breaks the marketing team.
Pegoretti — a working example
Dario Pegoretti was the framebuilder. The Italian master who painted bicycles like canvases. Pegoretti — the studio — continues his work. We've been their digital partner for years.
We replatformed Pegoretti to a fully bespoke headless site in 2026. Here's why it made sense in their specific case, and what we built.
Why a template wouldn't work. The Pegoretti site needed to do four things at once: tell the story of the workshop in Verona, present the model catalogue, support a paint-finishes browser called the Color Wall, and handle the act of commissioning a bike. The last one is not a checkout. It's a conversation. You don't add a Pegoretti to a cart — you contact the Bottega and discuss the build. This isn't a flow you can configure on Shopify; it's a flow we needed to design from scratch.
Why we built the commerce engine ourselves. Pegoretti commissions are unique objects with significant lead times and bespoke pricing. There's no inventory in the usual sense — every bike is custom. A Shopify catalogue would be the wrong shape. The commerce flow is custom code, integrated with Sanity for content and a custom database for commissions.
The stack. Next.js on the frontend, deployed to Vercel. Sanity for editorial content. A custom commerce flow that doesn't talk to Shopify at all — because Shopify wasn't the right tool for the job.
The result. A site that reads like the workshop it represents, with story-led architecture (find the brand, get to Verona, visit the Bottega), playful icons that nod to the Pegoretti studio, and a commission flow that respects how the business actually operates. Not a templated shop with a custom theme on top. You can see it at dariopegoretti.com.
Three questions to ask before you replatform
If you're considering going headless — or your current agency is recommending it — ask three things.
One. What specifically does going headless unlock for our business in the next twelve months? If the answer is "scale" or "future-proofing," press for specifics.
Two. What's the total cost of ownership for the first eighteen months, including ongoing engineering? This number is usually two to three times what brands expect.
Three. What's the design and editorial problem we're trying to solve, and could it be solved on our current platform with a redesign instead? Often the honest answer is yes.
If after asking those three questions the case for headless is still clear, go. The work is unbelievably good when it's right. If the answers aren't clear, fix the brand and the design first. The platform can wait.
One last thing
This piece exists because we'd rather you make a good decision than a fast one. We're platform-agnostic — we build on Shopify, WooCommerce, Magento, and headless stacks like the Pegoretti one above. Whichever fits your brand is what we'll recommend, and we'd rather not push you toward headless if it's not the right call. There are plenty of agencies who'll take that build regardless. We'd rather not be one of them.
If you're thinking about a replatform and want a real second opinion — written by a person, no AI — there's a sketch flow on this site at /sketch built for exactly that. Or write to us directly at hello@wewbd.com.