A fashion retailer's mobile app loads product pages in under a second and delivers a completely different browsing experience than their desktop website — same inventory, same prices, same cart, but each surface feels native to its context. Behind both is a single commerce backend. The frontend — the "head" — is decoupled from the system managing products, pricing, and orders. That's headless commerce, and it's both simpler and more complex than it sounds.
What Headless Commerce Actually Means
Traditional e-commerce platforms bundle the storefront and the backend together. Shopify themes, WooCommerce templates, Magento layouts — the frontend rendering and the commerce engine are tightly coupled. Headless commerce separates them: the commerce backend exposes APIs (product catalog, cart, checkout, orders, pricing), and your frontend team builds whatever presentation layer they want on top of those APIs.
The "head" — the part users see — is now a completely independent application. It could be a React SPA, a Next.js site with server-side rendering, a native iOS app, a voice interface, a kiosk, or all of these simultaneously. The backend doesn't care what consumes its API as long as the requests are authenticated.
The Architecture Underneath
A headless commerce stack typically has these layers:
- Commerce Engine — Manages products, variants, inventory, pricing rules, promotions, cart, and checkout. This could be a headless-native platform (Medusa.js, Vendure, Commercetools, Shopify Headless) or a custom-built service.
- Content Layer (optional) — A headless CMS (Contentful, Sanity, Strapi) handles editorial content — landing pages, blog posts, banners, category descriptions — separately from product data.
- Frontend Applications — One or more presentation layers consuming the above APIs. Each frontend owns its own rendering, routing, and UX.
- Infrastructure — API gateway, CDN for static assets, edge caching for product pages, and a background job queue for order processing and notifications.
| Component | Traditional (Coupled) | Headless (Decoupled) |
|---|---|---|
| Frontend changes | Require backend deployment | Independent deploys |
| Multiple channels | Separate platforms per channel | One backend, many frontends |
| Performance optimization | Limited by platform's rendering | Full control (SSR, ISR, edge) |
| A/B testing checkout | Limited to platform's tools | Full experimentation freedom |
| Initial complexity | Low | Medium–High |
| Time to first store | Days to weeks | Weeks to months |
When Going Headless Is the Right Call
Headless is not the default choice for every business. The architectural overhead is real, and the benefits only materialize when the business genuinely needs what headless delivers.
You're Running Multiple Storefronts or Channels
If you sell through a web store, a mobile app, a B2B portal, and a marketplace — all needing the same product catalog and inventory — a coupled platform forces you to maintain separate systems or hack integrations between them. A headless backend with APIs makes adding a new channel a frontend project, not an architecture overhaul.
Page Speed Is a Genuine Business Problem
Coupled platforms have a performance ceiling imposed by their rendering architecture. A Next.js frontend with Incremental Static Regeneration can serve product pages from edge nodes globally with sub-200ms TTFB. For high-traffic catalogs in competitive categories where conversion rate tracks closely with page speed, this matters — but you need the traffic volume for it to matter financially.
Your Design Requirements Outgrow Theme Constraints
When the UX you need requires significant workarounds within an existing theme system — custom checkout steps, complex configurators, dynamic pricing displays, personalized landing pages — the development time spent fighting the platform often exceeds what a clean headless frontend would cost to build.
Your Team Has Frontend Expertise
This is under-discussed: headless requires a capable frontend team. React, Next.js, state management, API integration, performance optimization, and deployment pipelines are all non-trivial. If your team's strength is in backend Python or your current developer works mainly in Liquid templates, headless adds risk.
When to Stay Coupled
Go headless only if you genuinely need it. The honest contra-indicators:
- You're launching a new store and need to validate product-market fit. The fastest path to revenue beats the cleanest architecture.
- Your team has limited frontend engineering capacity. A well-configured Shopify store beats a half-built headless system.
- Your catalog is small and your traffic is modest. The performance gains of headless matter at scale, not at 50 products and 500 daily visitors.
- You rely heavily on Shopify's app ecosystem. Many apps inject scripts directly into the Storefront theme — they don't work in a headless setup.
How to Build a Headless Commerce Architecture
Choose Your Commerce Backend
The choice depends on build-vs-buy appetite:
- Shopify Headless (Hydrogen + Storefront API) — Use Shopify's commerce engine, build your own React frontend with Shopify's Hydrogen framework. Best for teams already on Shopify who need frontend freedom but don't want to rebuild checkout and payments.
- Medusa.js — Open-source, self-hosted, Node.js commerce engine. Actively maintained, strong plugin ecosystem, no licensing cost. Good for teams comfortable with JavaScript backends.
- Vendure — TypeScript-native, GraphQL-first open-source commerce engine. Strong typing, good for complex catalog scenarios.
- Custom backend — Build your own. Appropriate when your pricing logic, inventory model, or order management requirements don't fit any existing engine. Higher cost, maximum flexibility.
Build Your Frontend Layer
Next.js is the dominant choice for headless commerce frontends because it supports all rendering modes: SSR for dynamic personalized pages, ISR for product pages that update without full rebuilds, and static export for landing pages. The combination lets you balance performance and freshness intelligently.
Structure your frontend with clear separation between the data-fetching layer (API calls) and the UI components. This makes swapping or upgrading the backend API much less disruptive.
Handle Search and Discovery
Search is one of the first places headless architectures show their seams. Algolia, Typesense, and Elastic are the standard choices — you index your product catalog from the commerce backend and query the search engine from the frontend. Get this right early; retrofitting search into a headless architecture after launch is painful.
Migration Path From an Existing Platform
Moving from a coupled platform to headless doesn't have to be a big-bang rewrite. A practical sequence:
- Build the new headless frontend in parallel with the existing site.
- Migrate traffic to the new frontend one URL group at a time, starting with the homepage and category pages (low-risk, high-visibility win).
- Run the new checkout on shadow traffic before switching all users.
- Maintain the old platform as a read-only archive until all historical data is confirmed correct in the new system.
Cost Ranges for a Headless Build
A realistic budget for a headless storefront built on Shopify Headless or Medusa.js, with a Next.js frontend:
- Lightweight (existing backend, new frontend only): $40,000–$90,000
- Mid-range (headless platform + custom frontend + search): $100,000–$200,000
- Full custom backend + frontend: $200,000–$500,000+
Offshore development can meaningfully reduce these figures while maintaining quality, particularly for frontend-heavy work where remote collaboration tools and component-driven development make geography less relevant.
Frequently Asked Questions
What's the difference between headless commerce and a PWA?
They're not the same thing, though they're often built together. Headless commerce refers to the architectural separation between frontend and backend. A Progressive Web App (PWA) is a specific type of web application that supports offline mode, push notifications, and home-screen installation. You can build a PWA that's headless, or a PWA that's tightly coupled, or a headless frontend that's not a PWA. Most modern headless commerce frontends are PWA-enabled, but it's not automatic.
Does going headless hurt SEO?
Done correctly, no — and it can help. Using Next.js with server-side rendering or Incremental Static Regeneration means search engines receive fully rendered HTML, not JavaScript-dependent pages that require client-side execution. Page speed improvements from headless architecture often improve Core Web Vitals, which Google uses as ranking signals. The risk is only if you build a client-rendered SPA without SSR — that configuration does create crawling challenges.
Can I use Shopify's checkout with a headless frontend?
Yes, and this is a very common pattern. Shopify's Storefront API lets you build any frontend you want while offloading checkout — including payments, fraud detection, and PCI compliance — to Shopify's hosted checkout. The trade-off is that you cannot fully customize the Shopify checkout experience on lower-tier plans; Shopify Plus gives checkout customization via Checkout Extensibility.
How long does it take to migrate from a traditional platform to headless?
A phased migration for a mid-sized store (5,000–50,000 SKUs) typically takes 3–6 months from start to full cutover. This includes building the new frontend, integrating with your commerce backend or a new headless platform, validating data integrity, and running parallel traffic before DNS cutover. Rushing this timeline is the single biggest risk factor.
This is the kind of work our team handles every day — learn more about our e-commerce development and custom development team.
The best way to de-risk a headless migration is to start with a bounded pilot — one market, one product category, or one channel — before committing to full migration. Talk to Mexilet Technologies about scoping a paid discovery sprint or a pilot engagement where you can validate the architecture and team fit before the full investment. It's a far better use of budget than a full rewrite that reveals surprises at month six.