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.
Reviewed against official documentation on July 24, 2026.
Hassan Jamal·Mar 14, 2026·15 min read
Headless commerce in plain English
- ✓The storefront renders the shopping experience.
- ✓Commerce services manage products, pricing, inventory, carts, customers, orders or checkout according to the chosen platform.
- ✓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.
Traditional vs headless commerce
| 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
- ✓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.
- ✓Complex merchandising, localization or integration requirements exceed the current implementation.
- ✓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
- ✓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 licence 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 licence 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 current visual-editing documentation 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.
Pros and cons
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 commerce cost?
PandaCodeGen planning tiers start at $1,500 Starter, $3,500 Growth and $5,000 to $10,000 Scale, but a headless commerce system may require custom scope. Price discovery, storefront templates, commerce capabilities, content, search, accounts, checkout, integrations, migration, QA, launch and operations. Add current vendor plans, usage, payment, hosting and support costs from the buyer's actual configuration. 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.
A headless decision checklist
- ✓What requirement is blocked today, and what evidence proves it?
- ✓Can a theme, app, content or infrastructure change solve it more safely?
- ✓Which system owns 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.
Standard payment is 30 percent at onboarding and 70 percent on delivery. Refund is tied to failure to deliver the signed scope. 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
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
Google Universal Commerce Protocol: Store Readiness in 2026
What UCP is, what Google currently documents for direct buying, what remains access-dependent and how merchants can prepare.
Slow Shopify Store Losing Sales? Build an Evidence Model
Join route-level field performance to your funnel, build bounded opportunity scenarios, test the least disruptive remedy and separate measured outcomes from assumptions.
Low Shopify Conversion Rate? Measure Speed in the Funnel
Segment the Shopify funnel by route, device, traffic source, and field performance before attributing conversion changes to speed or choosing a rebuild.