E-commerce architecture
What Is Headless Commerce? A Store Owner Guide
Headless commerce means you build the shop your customers see, and let one or more separate services handle the commerce behind it. That flexibility solves real problems when you need a particular experience or need to connect to other systems. It also leaves you with another application to secure, test and keep running.
Every Shopify figure on this page was read from Shopify's own pricing page and developer documentation on August 2, 2026.
Disclosure: PandaCodeGen builds headless storefronts, so we have a commercial interest in one side of this question. That is why this page publishes no speed uplift, no conversion figure and no market cost band, and why it puts the case for staying on a theme first.
Hassan Jamal·Mar 14, 2026·11 min read
Three Shopify store owners and developers, in their own words on r/shopify, on what apps and admin changes do to a themed store. Each quote links to the original post.
"One badly-written app that injects a synchronous script in the head can drag your LCP more than 15 well-written apps. Apps that load on every page when they only need to fire on product pages, third-party CDN dependencies, and any app whose JavaScript size is over 100kb — those three patterns cause 80% of the slowdowns we have seen.
u/Only-Fisherman5788 · r/shopify · May 5, 2026 · 5 upvotes · Verify source
"Our store has literally no front end apps whatsoever as I prefer to manually create them myself so I have full control over when they fire or not.
u/SimilarControl · r/shopify · May 5, 2026 · 8 upvotes · Verify source
"Feels like they are optimizing for new user simplicity at the expense of power users. Every update adds guardrails and abstraction, but kills speed for people who actually live in the admin all day. Death by a thousand clicks is real.
u/HusainKaizar · r/shopify · May 4, 2026 · 17 upvotes · Verify source
Headless commerce in plain English
The commerce platform stays the system of record for products, inventory, orders, customers and checkout. What moves to you is the storefront: its code, its hosting, its release process, and any customer-facing feature a theme or an app used to provide. Four parts, and the fourth is the one that gets left out of quotes.
- ✓The storefront renders the shopping experience.
- ✓The commerce service keeps hold of your products, prices, stock, carts, customers, orders and checkout, depending which platform you pick.
- ✓APIs and webhooks connect those parts with content, search, payments, analytics and operations.
- ✓Headless is an architecture choice, not an automatic speed, conversion or SEO result.
Storefront
Web, app, kiosk or another customer touchpoint.
APIs
Contracts connecting commerce, content and services.
Evidence
Field and lab measurements on real journeys.
Operations
Security, releases, observability and ownership.
"Going headless changes four things, and none of them is speed.
Traditional vs headless commerce
Four questions separate the two, and none of them is about speed. Rendering moves from a platform theme to an app you build and deploy. Commerce goes from native features to APIs exposing selected capabilities. The change surface splits, so frontend, APIs and providers now move independently. And responsibility for security, testing and operations transfers to your team.
| Question | Coupled storefront | Headless storefront |
|---|---|---|
| Rendering | Platform theme or native presentation layer | Separately built and deployed application |
| Commerce | Native platform features and extensions | APIs expose the selected commerce capabilities |
| Change surface | Usually fewer systems to coordinate | Frontend, APIs, providers and integrations can change independently |
| Responsibility | More platform-managed behavior | More application security, testing and operations owned by the team |
When headless commerce can be justified
These are six conditions that usually hold together, not a menu to pick one from. The first five describe a requirement the current platform genuinely cannot meet; the sixth asks whether your organization can own the engineering and operations that follow. A slow or visually limited store does not automatically need headless, and optimizing what you have is the cheaper answer when it can satisfy the requirement.
- ✓The required experience cannot be delivered reliably through the current theme or extension model.
- ✓Multiple customer touchpoints need one governed commerce layer.
- ✓Content, product and campaign workflows require a separate content system.
- ✓Your merchandising, translation or integration needs have outgrown what you have now.
- ✓Measured performance work remains constrained after realistic theme, media, app and infrastructure repairs.
- ✓The organization can own the additional engineering and operational responsibilities.
A slow or visually limited store does not automatically need headless. Optimize the current implementation first when that can satisfy the accepted requirement with less cost and risk. Work through Shopify speed diagnostics and theme-level inspection before treating architecture as the answer.
Is headless commerce faster?
It can be, but architecture alone proves nothing. A custom storefront can use deliberate rendering, caching, image, code-splitting and data-fetching strategies. It can also become slow through excessive scripts, poor queries, personalization, uncached work or large media. Compare the same representative product, collection, search, cart and content journeys using field Core Web Vitals where available and repeated lab tests under recorded conditions. Our Core Web Vitals reference defines the thresholds, and what a PageSpeed score represents explains why a single lab run settles nothing.
We do not put a headline speed improvement on this page, because going headless does not carry one. The result depends on what the storefront renders, what it caches, how much media and script it ships and how the data layer is built, and a replatform done carelessly can land slower than the theme it replaced. Establish your current numbers on the journeys that matter to you first, then hold any proposed architecture to those same measurements.
Examples of headless commerce patterns
These are architecture examples, not outcome claims. Each pairs a commerce backend with a separately deployed storefront, and each carries its own versioning and support model. Current product behavior and plan limits still need checking when you scope a project, because these move.
- ✓A Shopify backend with a Hydrogen storefront and Shopify-hosted Oxygen deployment.
- ✓A Shopify backend with a separately hosted frontend using the Storefront and Customer Account APIs.
- ✓A Medusa application with an independently built Next.js storefront using Store API routes.
- ✓A commerce backend combined with Sanity for editorial content and visual editing.
- ✓One commerce layer serving a website plus other authorized customer touchpoints.
These are architecture examples, not outcome claims. Shopify documents a versioned Storefront API and recommends stable-version updates each quarter. Medusa documents a separate server, admin and storefront. Sanity documents visual editing for connected frontends. Current product behavior and plan limits still need to be checked when scoping a project. We describe the content-plus-frontend pairing we use most often in the Next.js and Sanity stack, and the hosting side in what it takes to host a Next.js frontend.
Shopify headless: Hydrogen or your own stack
Shopify's Storefront API exposes commerce capabilities such as products, collections, contextual pricing and carts. The Headless channel manages storefront tokens, permissions, publishing and attribution. Hydrogen is Shopify's supported React-based option, while Shopify also documents bringing another stack. API versioning, customer accounts, consent, checkout behavior, extensions and plan-specific needs belong in the technical discovery. Our guide to headless Shopify decisions covers that discovery in more detail, and Shopify compared with a custom build frames the wider platform question. We deliver this work through our ecommerce engineering service.
Medusa as a commerce backend
Medusa separates its Node.js application and admin from the storefront. Its documentation supports building a storefront independently or starting from a Next.js storefront, with Store API routes and publishable keys connecting the application. This offers implementation flexibility, but the buyer must account for the commerce server, database, providers, storefront and operational ownership rather than comparing license labels alone. The same ownership question applies to any self-hosted stack, which is the ground covered in WooCommerce compared with a custom build and on our WooCommerce service page.
| Decision point | Headless Shopify | Medusa |
|---|---|---|
| Backend | Shopify runs payments, inventory, checkout and fraud tooling | You run the commerce application, database and providers |
| Recurring platform fee | Shopify plan and app fees continue to apply | No license fee; Medusa is MIT-licensed. You pay for hosting, database and services instead |
| Payments and PCI | Handled within Shopify's scope | Your responsibility, or your hosting provider's, to integrate and document |
| Operational load | Storefront only; the backend is somebody else's uptime problem | Storefront plus commerce server, upgrades, backups and incident response |
| Suited to | Teams happy with Shopify's backend who want off Liquid | Teams that want no platform dependency and have capacity to operate it |
The MIT license removes a license fee, not the work. Someone still has to run the commerce server, patch it, back it up, and answer the phone when checkout breaks at midnight. Compare total operating cost and who is accountable for uptime, not the license label.
Where a headless CMS fits
Product truth can remain in the commerce system while campaign pages, guides and editorial modules live in a content platform. Sanity's visual-editing documentation, read August 2, 2026, describes live previews and direct editing from the rendered page. Define which system owns each field, how product references resolve, who can publish and what happens when one system is unavailable.
Design freedom, omnichannel and faster updates: what each one actually costs
Those three are the benefits almost every headless explainer leads with, and all three are real. None of them is free, and the cost is rarely in the same sentence as the benefit. Design freedom means the storefront is now code you own, so a visual change that used to be a theme setting becomes a development task and a deploy. Omnichannel means the commerce layer serves several surfaces, which is genuine leverage once you have a second surface and an overhead until you do.
The third one is worth reading carefully, because it is often stated backwards. Headless does not remove a release process, it adds one. A themed storefront publishes from the platform; a headless storefront builds, deploys and has to be rolled back by somebody. That can absolutely be faster, and on a team with continuous deployment it usually is, but the speed comes from the pipeline you now operate rather than from the architecture itself. If nobody owns that pipeline, updates get slower, not quicker.
Worth knowing where the usual answer comes from: the explainers that rank for this question are mostly published by commerce platforms that sell headless products. That does not make them wrong, and we sell headless builds too, which is why the disclosure sits at the top of this page. It does mean the cost column is the part you will have to go looking for, so here it is in the same place as the benefits.
Pros and cons
Read the two columns at different confidence levels. Everything on the left is something headless makes possible; everything on the right is something it makes certain. The advantages depend on how well you build, and the added responsibilities arrive regardless.
Potential advantages
- ✓Experience and frontend stack can be designed around the requirement.
- ✓Multiple channels can use governed commerce services.
- ✓Teams can choose explicit rendering, caching and deployment strategies.
- ✓Content and commerce workflows can be separated where useful.
Added responsibilities
- ✓Another application, dependency graph and deployment process.
- ✓API versioning, availability, rate limits and failure handling.
- ✓Preview, search, analytics, consent and merchandising integration.
- ✓Regression testing, security, observability and engineering ownership.
SEO and product discovery
Preserve crawlable rendered content, stable product and collection URLs where practical, canonicals, internal links, status codes, sitemaps and accurate product structured data that matches visible content. Test variants, pagination, faceting and unavailable products. A framework or schema type does not guarantee indexing, rich results, rankings or AI citations. If the storefront move also changes URLs, read what happens to search visibility during a migration.
How much does headless Shopify cost?
Going headless on Shopify does not replace your Shopify bill, it adds a storefront to it. Read from Shopify's own pricing page on August 2, 2026, the plan lineup is Basic at US$19/mo, Grow at US$49/mo, Advanced at US$299/mo and Plus from US$2,300/mo, with third-party payment provider fees of 2%, 1%, 0.6% and 0.2% respectively. The page carries a yearly and monthly toggle and regional pricing, so read it in your own market on the day you budget. On top of that plan you pay for the storefront build, then for hosting, a content system and search if you use them, then for whoever keeps the storefront running afterwards.
Two things are worth correcting before you use any published breakdown. Several of the cost articles ranking for this query still quote Shopify's entry plan at $29 a month, where Shopify's own page said US$19 when read on August 2, 2026. Several also skip the Grow plan at US$49 entirely, which is the tier a store outgrowing Basic actually lands on. If a cost article gets the platform line wrong, treat its build ranges with the same suspicion.
Is Shopify headless free?
The framework is, the hosting is not documented, and the store plan definitely is not. Hydrogen, Shopify's own React storefront framework, ships under the MIT license (Copyright 2023-present, Shopify Inc.), so you can read it, fork it and run it anywhere at no license cost. Oxygen is the part most often repeated without a source. The widely published claim that “Hydrogen and Oxygen are free” does not appear on Shopify's pricing page or in its Hydrogen and Oxygen developer documentation, both read August 2, 2026, neither of which stated an Oxygen price. What it does document is that deployments are tied to a Shopify store, and that shareable deployment links require the Basic plan or above.
That gap matters when you are building a three-year budget, because the one line you cannot look up is the one every summary assures you is zero. Ask Shopify directly what Oxygen costs on your plan and at your traffic before you commit to it, and get the answer in writing. If you host the storefront yourself instead, the cost moves to your own provider and becomes checkable again; what it takes to host a Next.js frontend sets out what that line actually looks like.
What you give up when you go headless
The editing experience, and it is the loss teams most often underestimate. A headless storefront is your own application, not a Liquid theme, so Shopify's theme editor does not apply to it. Neither do theme app extensions or any app that works by injecting itself into a theme. Anything a merchandiser used to change by dragging a section now needs either a content system wired up for the purpose or a developer. Checkout stays on Shopify, which is the part you want to keep, but everything in front of it becomes code you own.
Price that before you price the build. A storefront nobody on the marketing team can edit will get edited by the engineering team, and that is a recurring cost dressed up as a one-off. The honest version of this project includes whatever it takes to give the people who run campaigns their controls back.
What we charge for this work
A headless commerce build is normally custom scope rather than a standard tier. Our published tiers start at $1,500 Starter, $3,500 Growth and $5,000 Scale, and a storefront with its own commerce integration, content system, search, accounts and migration usually sits beyond Scale. Those are our prices, not a market average, and we would rather say so than anchor you on an entry figure that does not apply to this job. The full tier detail sits on the pricing page, and the line items that push a project past a standard tier are set out in the rebuild scoping guide.
Is headless Shopify worth it?
For most stores, no, and the reason is specific rather than cautious. Headless buys you control of the storefront and costs you the theme editor, an ongoing engineering commitment and a hosting line Shopify does not publish a price for. It is worth it when you can name a requirement the theme demonstrably cannot meet after you have actually tried, when you have somebody who will own the storefront application after launch, and when the people who run campaigns will still be able to change a page without filing a ticket. Two out of three is not enough; the third one is where these projects quietly fail.
The version of this question worth asking is not whether headless is better but what you are buying instead. The same budget spent on the existing theme, its images, its app load and its data layer usually moves the numbers that matter further, and it does not add an application to your maintenance. Run that comparison honestly before you commit; the Shopify speed diagnostics are the cheaper half of it, and if they close the gap you have saved a rebuild.
A headless decision checklist
Seven questions, and the first two decide the rest: what requirement is blocked today, what evidence proves it, and could a theme, app, content or infrastructure change solve it more safely. If you cannot answer those with something specific, the remaining five are premature.
- ✓What requirement is blocked today, and what evidence proves it?
- ✓Can a theme, app, content or infrastructure change solve it more safely?
- ✓Which system is the source of truth for products, content, customers, orders, payments and search?
- ✓Which platform capabilities are available through the chosen APIs?
- ✓Who owns security, releases, incident response and API upgrades?
- ✓What are the baseline, acceptance profiles, rollback plan and business guardrails?
- ✓What is the three-year cost using current vendor quotes and internal effort?
PandaCodeGen's approach
We begin with a free fit audit and only recommend a custom storefront when the documented requirements justify it. Panda Patches is owned by a PandaCodeGen co-founder and can be described as a first-party architecture example, but this article does not claim unverified speed, conversion or revenue results for it. Client accounts can remain under client control, reusable internal tools remain PandaCodeGen property, and third-party components retain their licenses according to the signed terms.
A common payment option is 30 percent at onboarding and 70 percent at the delivery milestone, and another written schedule may be agreed. Refund is tied to failure to deliver the signed scope. Where the accepted project terms record it, Starter includes 15 business days of launch defect support; Growth and Scale include 30. Performance acceptance applies only to the named pages, profiles, environment, repeated runs, exclusions and remedy in the contract.
Frequently asked questions
Frequently Asked Questions
Is headless Shopify worth it?
For most stores, no. Headless buys you control of the storefront and costs you the theme editor, an ongoing engineering commitment, and a hosting line Shopify publishes no price for. It is worth it when you can name a requirement the theme demonstrably cannot meet after you have actually tried, when somebody will own the storefront application after launch, and when the people who run campaigns can still change a page without filing a ticket. Two out of three is not enough, and the third is where these projects quietly fail. The same budget spent on the existing theme, its images, its app load and its data layer usually moves the numbers further and adds nothing to maintenance.
What is headless commerce in simple terms?
Headless commerce separates the customer-facing storefront from one or more commerce services. APIs and webhooks connect products, pricing, inventory, carts, customers, orders, checkout, content and other systems according to the chosen architecture.
How much does a headless commerce build cost?
A headless commerce build is normally custom scope rather than a standard tier. PandaCodeGen's published tiers start at $1,500 Starter, $3,500 Growth and $5,000 Scale, and a storefront carrying its own commerce integration, content system, search, accounts and migration usually sits beyond Scale. Those are our prices, not a market average. Budget the storefront build, then hosting, a content system and search if you use them, then whoever keeps the storefront running afterwards.
How much does headless Shopify cost per month?
Going headless does not replace your Shopify bill, it adds a storefront to it. Read from Shopify's own pricing page on August 2, 2026, the plan lineup is Basic at US$19/mo, Grow at US$49/mo, Advanced at US$299/mo and Plus from US$2,300/mo, with third-party payment provider fees of 2%, 1%, 0.6% and 0.2% respectively. Regional pricing and a yearly or monthly toggle both change what you see, so read it in your own market. Most published breakdowns still quote the entry plan at $29 and omit the Grow tier entirely.
Is Shopify headless free?
The framework is, the hosting is not documented, and the store plan is not free at all. Hydrogen, Shopify's React storefront framework, ships under the MIT licence (Copyright 2023-present, Shopify Inc.), so there is no licence cost. The widely repeated claim that Oxygen hosting is free does not appear in Shopify's developer documentation, which publishes no Oxygen price. The documentation states that deployments are tied to a Shopify store and that shareable deployment links require the Basic plan or above. Ask Shopify what Oxygen costs on your plan and at your traffic, and get the answer in writing.
What do you lose by going headless on Shopify?
The editing experience. A headless storefront is your own application rather than a Liquid theme, so Shopify's theme editor does not apply to it, and neither do theme app extensions or any app that works by injecting itself into a theme. Anything a merchandiser used to change by dragging a section now needs a content system wired up for the purpose or a developer. Checkout stays on Shopify; everything in front of it becomes code you own.
Do I need headless commerce for my store?
Use headless when verified experience, channel, content, integration or operating requirements cannot be met safely by the current storefront and your team can own the added application. Product count and traffic alone do not decide it.
Will I lose my products and orders if I go headless?
A storefront-only change can retain the commerce backend, but data, API scopes, customer accounts, search, checkout, apps and integrations still require inventory and validation. Do not promise that nothing changes or can be lost without testing the actual implementation and rollback.
Is headless commerce faster than Shopify?
Headless can support deliberate rendering, caching and data strategies, but it can also be slow. Compare representative product, collection, search, cart and content routes using field Core Web Vitals where available and repeated lab tests under recorded conditions.
What are some headless commerce examples?
Documented patterns include Shopify with Hydrogen, Shopify with another frontend using Storefront and Customer Account APIs, and Medusa with an independently hosted storefront. A separate content platform such as Sanity can support editorial workflows. These examples describe architecture, not guaranteed outcomes.
What are the pros and cons of headless commerce?
Potential benefits include experience flexibility, multiple touchpoints and explicit rendering choices. Costs include another application, API dependencies, preview and search integration, consent and analytics work, regression testing, security, monitoring and ongoing engineering ownership.
Primary sources
- Shopify Storefront API
- Shopify bring your own stack
- Shopify Hydrogen releases
- Medusa storefront development
- Medusa production optimization
- Sanity Visual Editing
- Shopify plan pricing
- Hydrogen license (MIT)
- Shopify Hydrogen deployments
Find out whether headless is justified
We will compare repair, theme, headless and full-platform options against the same requirements, operating model and acceptance evidence.
Related Articles
Meta Ad Tracking Not Working? A 2026 Diagnostic Guide
A consent-aware method for reconciling orders and Meta events, debugging browser and server delivery, and preventing duplicate events.
Meta Conversions API Setup Cost: A Scope-Based Guide
Plan Meta Conversions API cost from events, systems, consent, matching, deduplication, QA and monitoring, with a carefully labelled Panda Patches screenshot.
Spending More on Ads but Getting Fewer Orders? Audit Tracking
Reconcile platform events with the system of record, diagnose browser and server coverage, and improve consented measurement without assuming attribution or performance lift.