What the two terms mean
In traditional ecommerce, one system does everything. The platform stores products and orders, and the same platform draws the pages customers see, through a theme. Change the theme and the storefront changes. This is how most stores on hosted platforms and on WooCommerce work.
In headless ecommerce, the two halves are separated. A commerce backend keeps the catalog, the cart, the orders and usually the checkout. A storefront built as its own application asks the backend for data through an API and presents it however you like. The head, meaning the part customers see, is no longer attached to the body.
The two approaches at a glance
| Traditional | Headless | |
|---|---|---|
| Storefront | A theme, configured or customized | A custom application, built for your brand |
| Design freedom | Within what the theme system allows | Open. Any layout, any interaction |
| Speed | Depends on the theme and the apps added to it | Under your control, and usually faster when built with care |
| Other channels | One website. Other channels need separate work | The same backend can serve a site, an app, a kiosk or a marketplace feed |
| Apps and plugins | Install and they appear in the store | Backend apps keep working. Apps that change the storefront need rebuilding |
| Content editing | In the platform's page editor, with live preview | In a CMS connected to the storefront. Preview has to be set up |
| Team | A merchant team, with a developer now and then | Developers for the storefront, on an ongoing basis |
| Cost | Lower to start and to run | Higher to build and to maintain |
When each one fits
Stay traditional when
- A theme, well adjusted, expresses your brand
- The store's speed is already good on phones
- Marketing changes pages and campaigns without developers
- You rely on many storefront apps
- There is no developer budget after launch
Go headless when
- The shopping experience is part of what makes you different
- Speed measurably limits your conversion and the theme is the cause
- One catalog must feed a website, an app and other channels
- Editorial content and products belong on the same pages
- A development team will own the storefront for years
What headless really costs
The build is the visible cost. Four others arrive later and are easier to miss.
- Two systems to run. The storefront is deployed, monitored and updated separately from the backend, and a release can break the link between them.
- Lost storefront apps. Reviews, upsells, search and loyalty widgets that worked by installing an app now need an integration written for each.
- Preview and editing. Marketers used to seeing changes as they type need a preview set up for them, and each new kind of page section needs a developer.
- A permanent developer. A theme can sit untouched for a year. A custom storefront has dependencies to update and somebody has to do it.
None of this is a reason to avoid headless. It is the price, and it should be weighed against a gain you can name: a faster store, a design no theme can produce, or channels a single website cannot serve.
Steps in between
The choice is not all or nothing. Many stores keep the platform's checkout and customer accounts, which are the hardest parts to get right, and replace only the pages before them. Others begin with the home page and the product page, where speed and presentation matter most, and leave the rest on the theme until there is a reason to move it.
Going the other way is possible too. A store that tried headless and found the upkeep too heavy can return to a theme, since the backend and its data never left. Our comparison of Shopify and custom ecommerce describes the same middle path from the platform's side.
A worked example
A coffee roaster and a sportswear brand
Both companies are invented. Both run on a hosted commerce platform.
- The coffee roasterSells 40 products and subscriptions. The owner updates the site herself, and a paid theme with four apps does the job.
- Its decisionTraditional. Nothing about the store is limited by the theme, and there is nobody to maintain a custom storefront.
- The sportswear brandSells in six countries, launches collections with rich editorial pages, has an app, and measures a drop in sales whenever pages slow down.
- Its decisionHeadless. A custom storefront and the app share one backend, content and products are mixed freely, and a team of developers owns performance.
The roaster would have paid for freedom it had no use for. The brand was already paying for the limits of its theme.
A checklist to decide
Tick what is true. The first four favor staying traditional. The last four favor headless.
Traditional or headless
0 of 8 checkedWhat to do next
Before choosing, measure. Record how fast your key pages load on a phone and list every change the theme has stopped you making in the past year. A short list means the theme is not your problem. A long one is the case for a custom storefront, which we build with Next.js on your existing backend.
If you would like a second view on the list, send it to us.
Common questions
Is headless ecommerce faster?
It can be, and usually is when built carefully, because the storefront loads only what each page needs and is not carrying scripts from a dozen apps. It is not automatic. A poorly built headless storefront can be slower than a lean theme. If speed is your reason, set a target for your key pages and hold the build to it.
Do we lose our apps and plugins when we go headless?
You keep the ones that work in the backend, such as tax, shipping, inventory and order management. You lose the automatic appearance of apps that add something to the storefront, such as reviews, product recommendations or pop-ups. Many of those offer an API, so they can be rebuilt into the new storefront, but each one is work to count before you decide.
Can we go headless later without changing platform?
In most cases, yes. The major commerce platforms expose their catalog, cart and checkout through APIs, so a custom storefront can be placed on top of the store you already run. Products, customers and order history stay where they are. That makes headless a step you can take when the need appears, not a decision to make on the first day.
Is headless only for large companies?
It suits companies with a development team or a retained partner, which tends to mean larger ones. Size itself is not the test. A small brand whose whole appeal is its online experience may justify it, and a large distributor with a plain catalog may not. The question is whether a better storefront would earn more than it costs to keep.
