Headless commerce: when it is worth it and when it is hype

In a traditional store, one platform does everything. Shopify, BigCommerce, Magento or WooCommerce stores the products, runs the cart and checkout, and renders every page using its own templating system. Change the look and you edit a theme inside the platform's constraints.

A headless setup splits that in two. The commerce platform keeps doing the commerce work and exposes it through APIs: Shopify's Storefront API, BigCommerce's Storefront and Management APIs, Magento's REST and GraphQL endpoints, or API-first platforms such as commercetools and Elastic Path. A separate front end, often built with React, Vue, Gatsby or Next.js and hosted on a service like Netlify or Vercel, requests data from those APIs and renders pages however the team decides. Content usually lives in a third system, a headless CMS such as Contentful, Prismic or Sanity, which the front end also pulls from.

The practical consequences:

• You own the front end. Any design, any interaction, any page structure. No theme limitations.
• One back end feeds many heads. The same catalog and cart can power a website, a native app, an in-store kiosk, a voice assistant or a marketplace feed.
• Content and commerce mix freely. Editorial pages can embed live product data, and product pages can pull rich content, without the platform's page builder getting in the way.
• You take on the glue. Search, filtering, SEO metadata, page caching, previews for editors, checkout handoff and analytics all become your responsibility rather than the platform's.

Most of what you read about headless comes from vendors who sell it. Here is what the build and the operation actually involve.

Beyond money, three things catch teams out.

Editor experience gets worse before it gets better. A merchandiser used to dragging sections around in Shopify's theme editor now works across a CMS, the commerce admin and a deployment pipeline. Previewing a page can require a developer until you build a preview system.

Checkout is rarely fully headless. On Shopify, checkout still happens on Shopify's domain unless you are on Shopify Plus. On most platforms, the safest path is to build everything up to the cart and hand off to the platform's hosted checkout, which means the brand experience breaks at the most important step unless the handoff is designed carefully.

Apps stop working. The hundreds of plugins that add reviews, upsells, loyalty and search to a themed store inject their code into the theme. In a headless build, each of those features needs an API integration or a rebuild. Budget for it line by line.

A decision rule we use: headless is justified when at least two of the following are true.

1. You sell through more than one surface. A web store plus a native app, retail screens, a wholesale portal or a marketplace, all needing the same catalog and pricing logic.
2. Content is your acquisition engine. Publishers moving into commerce, brands whose SEO depends on long-form editorial, or stores whose product pages need rich storytelling that a product template cannot hold.
3. The platform's front end is a measurable ceiling. You have already optimized the theme, you are on fast hosting, and you still cannot hit the speed, personalization or design requirements the business has set.
4. Revenue supports an engineering team. Online revenue above roughly $5 million to $10 million a year, or a funded plan to reach it, with developers who will stay with the stack.
5. You are replatforming anyway. If a Magento 1 end-of-life migration or a move off a custom legacy system is already on the roadmap, deciding the front end separately from the back end is cheap.

If only one applies, a well-built theme on a modern platform will get you most of the benefit for a fraction of the cost. If none apply, headless is a technology preference, not a business decision.

Be skeptical when the reasons given are:

• "Page speed." A tuned theme with optimized images, minimal apps and a CDN routinely loads in two to three seconds on mobile. If your store is slow, audit the apps and images before rebuilding the architecture.
• "Future-proofing." Every platform now has APIs. You can go headless later without replatforming, so there is no advantage in doing it before you need it.
• "Our developers prefer React." Developer preference is a real cost consideration, but it is the business that pays the retainer.
• "Everyone is doing it." A small number of large brands have published case studies. The majority of stores earning under $10 million a year are not headless and do not need to be.

You do not have to choose between a stock theme and a full custom front end.

Progressive Web App layers. Magento's PWA Studio and Vue Storefront give a modern, app-like front end on top of existing platforms with some of the community support a theme would have. They are still substantial builds, but less bespoke.

Headless content, themed commerce. Keep the store on its native theme and move marketing pages, blogs and landing pages to a headless CMS rendered by a static site generator. You get the content flexibility where it matters and keep the platform's commerce experience and apps intact.

Platform-native customization first. Shopify's Sections, BigCommerce's Stencil and Magento's layout system allow far more than most stores use. Exhaust those before paying for freedom you may not exercise.

• Which checkout will customers use, and how does the handoff look and feel?
• Who edits pages day to day, and how do they preview changes?
• Which current apps and integrations must be rebuilt, and what does each one cost?
• How will search, filtering and SEO metadata be handled?
• Who owns the front end in two years, and what happens if they leave?
• What does the platform cost at your projected order volume once API usage and enterprise tiers are included?

A written answer to each of these is the minimum before signing a build contract.

We start from the business, not the stack. Discover: map every channel you sell through today and plan to, audit the current store's real performance, and list the integrations and editorial workflows that must survive. Plan: score the headless decision rule honestly, compare a themed rebuild, a hybrid and a full headless build on cost, time and risk, and choose the platform and front-end approach that the team can sustain. Build: design and develop the storefront, content system and integrations with checkout, search and analytics handled as first-class work rather than afterthoughts. Improve: conversion testing, speed monitoring and a release rhythm so the custom front end keeps paying for itself. Brand, growth, web and technology work together because a storefront decision touches all four.

A representative engagement is our ecommerce work, where a retailer with a strong editorial audience had outgrown a themed store that could not combine rich content with live product data. Rather than rebuilding everything, we kept the commerce platform, moved content into a headless CMS, and built a front end that merged the two, with a carefully designed handoff to the platform's checkout. The result was a faster site, far more flexible pages for the content team, and a catalog ready to serve a second channel the business was planning.