How does headless commerce work, and is it right for your online store?

Headless commerce splits an online store into two separate programs: the storefront your customers see, and the commerce back end that holds products, prices, carts, checkout and orders, with APIs carrying data between them. It's the right call for a store whose theme can't do what the business needs and that has developers to look after a custom front end long after launch. For most stores selling a standard catalog in one or two markets, a well-built theme is still the better buy.

The question comes up when a theme starts to feel tight. A designer wants a product page the theme can't produce, a mobile app is on next year's plan, or the content team has outgrown blog posts squeezed between collections. Someone then pitches a headless rebuild as the fix for all three. Sometimes it is the fix, and sometimes the store pays for a custom application to solve problems a theme developer could have fixed.

How headless commerce works, one page view at a time

In a headless store, the front end and the back end are two programs that talk over the network. The back end is the commerce platform: Shopify, BigCommerce or another engine that stores the catalog, runs the cart, takes payment and records the order. The front end is a separate web app your developers build in a framework such as React Router or Next.js. Neither depends on the other's code, so you can redesign the storefront without touching how orders are processed.

Follow one shopper through it and the moving parts get clear:

1. A shopper opens a product page, and the request goes to your front end rather than to the commerce platform.
2. The front end asks the platform's API for that product's title, images, variants, price and stock. On Shopify this is the Storefront API, which only speaks GraphQL, a query format where the front end names exactly which fields it wants back.
3. Using that data, your app builds the page in whatever layout your designer chose and sends it to the browser.
4. The shopper taps "Add to cart", the front end passes that to the API, and the platform keeps the cart.
5. At checkout, the shopper is handed to the platform's own checkout, which takes payment and creates the order in the same admin your team already uses.

Two more pieces sit beside that flow. Content that isn't product data, such as lookbooks, buying guides and campaign pages, lives in a content management system (a CMS) that the front end also calls. One back end can also feed several front ends. A website, an iOS app and an in-store screen can all read the same catalog and write to the same order list.

Compare that with a theme store. On Shopify, a theme is written in Liquid, Shopify's template language, and Shopify renders and hosts every page for you. That bundled presentation layer is the "head" in the name. Going headless means removing it and putting your own front end in its place.

What Shopify's headless toolkit looks like in October 2026

Shopify's headless documentation puts it in two sentences: you build the frontend, and Shopify's APIs handle the commerce underneath. The toolkit around that idea has five parts, and a store doesn't need all of them.

The Storefront API does most of the work. It serves products, collections, search and the cart, then hands the shopper to Shopify's checkout. Requests from real shoppers aren't held to a fixed per-minute limit, which is what you want on a sale day. Its partner, the Customer Account API, handles sign-in and gives the front end each customer's orders, addresses and profile.

Hydrogen has just changed shape. Earlier versions were React Router apps with Shopify's components and settings pre-installed, so choosing Hydrogen meant choosing its framework. On 14 October 2026, Shopify released the new Hydrogen as a framework-agnostic JavaScript library, with ready starters for React Router and Next.js. For example, a team that already runs a Next.js marketing site can add product pages and a cart to it, rather than rebuilding the whole site inside Shopify's framework.

Oxygen is Shopify's hosting for Hydrogen storefronts. It runs your front end at the edge from more than 300 points of presence and costs nothing extra on paid plans from Starter through Plus. Hydrogen also runs on Vercel, Cloudflare or your own Node servers. Teams that would rather not use a Shopify toolkit at all call the APIs directly, in any language, and manage access through the Headless channel in the Shopify admin.

Shopify is the worked example here because its tools are documented in one place. A team can also build and test a Hydrogen storefront on a development store before the real store goes live. BigCommerce and Salesforce Commerce Cloud offer the same pattern under their own names.

What a headless store asks of you in build and upkeep

A headless store costs more to build and more to run than a theme store, and Shopify says so plainly in its own docs. Before committing, its docs tell developers to make sure the merchant "accepts the added cost and complexity, and has developers to maintain the storefront after launch." In our view that second condition decides more projects than the first.

The build is the visible bill. BigCommerce estimates a mid-market headless implementation at $50,000 to $150,000, with enterprise builds going past $250,000. Those are one vendor's figures, not a quote for your store. They do show the scale: you're paying for a custom web application, where a theme project buys design and setup on top of code someone else maintains.

The upkeep is the bill people forget. Shopify releases a new API version every three months, and each stable version is supported for at least 12 months. A theme store gets those changes from Shopify. A headless store has to move its own code to a newer version before the old one expires. Plan for at least one upgrade a year, a full test of cart and checkout each time, and someone paid to do both.

Price these in from the start too:

• A CMS subscription and the hours to set up your content in it, because the visual theme editor your marketers used is gone.
• App work. Many Shopify apps add reviews, ratings and similar widgets through theme app extensions, which plug into Online Store 2.0 themes. A headless front end has no theme for them to plug into, so a developer connects each one through the app's own API, if it has one.
• Hosting, monitoring and error tracking, unless Oxygen covers the hosting.
• Developer time for every front-end change, from a new banner layout to a broken filter. Front-end bugs are now yours to find.

Run the numbers on a store doing $40,000 a month. Say a $90,000 rebuild lifts revenue by a tenth, which is a generous result. At a 40 percent gross margin, that's $1,600 a month of extra profit. The build alone takes close to five years to pay back, before a single hour of retainer. The maths looks different when the rebuild opens a new channel, like a mobile app, instead of polishing the one you already have.

Pros and cons, without the sales pitch

For the stores that need them, the gains are real. Design freedom comes first: any layout, interaction or page type your front-end team can build is on the table, with no working around theme sections. One back end can serve a website, a native app built on the Storefront API and Shopify's Checkout Kit, and other screens, all sharing one catalog and one order history. Commerce slots into a stack you already run, whether that's a CMS, a Next.js site or a custom app. And the front-end team ships on its own release schedule while checkout and payments stay on a hosted platform.

The drawbacks are mostly the costs above: a bigger bill every year, developers on hand for as long as the storefront exists, and app and content work the theme used to absorb. One more belongs on the list. Page speed becomes your job.

That one needs a closer look, because speed sits near the top of most headless pitches. Speed does pay. Google commissioned Deloitte and the consultancy 55 to track 37 brand sites and more than 30 million sessions over 30 days. A 0.1 second improvement in mobile site speed came with an 8.4 percent rise in retail conversions. But a custom front end is only as fast as the team that builds it, and a heavy JavaScript bundle can load slower than a lean theme. Check your Largest Contentful Paint first. Google's target is 2.5 seconds or less for 75 percent of page loads. If oversized images or too many apps keep your theme above it, fix those before paying for a rebuild.

Which stores gain from headless commerce

Shopify's own test is a sound one: go headless when the business systems, processes or customer experience you need can't be achieved with its sales channels, themes and apps. Put into store terms, the stores that gain look like this:

• A brand that sells through a website and a native mobile app and wants both on one catalog and one order list.
• Content-led brands, say a fashion label with editorial lookbooks or a food brand built on recipes, where the CMS carries the business and the shop sits inside it.
• Companies that already run a custom web app or Next.js site and want to add commerce to it. The new Hydrogen library was built for this case.
• Groups running several brands or regional storefronts off one back end, each with its own design.
• Anything a theme can't present well, like a configurator with live pricing across thousands of combinations.

Stay on a theme if you sell a standard catalog in a handful of markets, your marketing team edits pages themselves every week, and nobody on staff or on retainer can own a JavaScript app. The same applies when slow pages come from images or apps, or when the budget covers the build but not the year after it.

Picture two stores. The first sells 300 skincare products in two countries, its theme loads in under two seconds, and its growth plan is more ads and more email. A headless rebuild would add a monthly developer bill and change nothing a customer notices. The second sells made-to-order furniture with 40,000 fabric, size and finish combinations, runs a mobile app, and has a developer in-house. Its theme is blocking the product page it needs, and that store is the one that gains.

The honest exception is going early on purpose. A brand with a funded, dated plan to launch an app or a second brand within 18 months can save itself a second rebuild by building the website headless now. If that plan is a "someday", wait.

Lighter options before a full rebuild

Headless isn't all or nothing. Shopify's build options include several smaller ways to use the same APIs:

• Add products and buy buttons to a site you already have, with Storefront Web Components or Buy Button JS.
• Sell Shopify products on a WordPress site through the Shopify Plugin for WordPress.
• Add the new Hydrogen library to one part of an existing app, such as a product finder, and leave the rest alone.
• Keep the theme for the main store and build one headless piece beside it, such as a mobile app reading the same catalog through the Storefront API.

Each one lets you find out whether custom front-end work earns its keep before the whole store depends on it.

Questions to answer before you commit

Ask these inside your team, and ask any agency quoting the work to answer them too:

1. What can't our theme do today? Write the list. If it fits on two lines, a theme developer can probably solve it.
2. Who maintains the front end after launch, and how many hours a month have we budgeted for them?
3. Who runs the yearly API upgrade, and how do we test cart and checkout each time?
4. Which apps does the store depend on, and does each one have an API a custom front end can call?
5. Where will marketers edit pages, and have they tried that CMS with real content?
6. Is the speed problem measured against the 2.5 second target, and have images and apps been ruled out as the cause?

A good partner raises these before quoting a headless build. One who quotes without asking has priced the build and not the years after it.

If you're weighing a headless rebuild against a better theme, send the Techno Mantraa team your store's details at info@technomantraa.com for a custom quote.