One catalogue. Any storefront.
Keep Shopify or your commerce engine for products, orders and payments. Build the storefront separately, so speed and design are yours to decide — and the same catalogue feeds your app and marketplaces too.
Headless means your storefront is built separately from your commerce backend, connected by API. You get faster pages, complete design freedom, and one product catalogue serving web, app and marketplaces. It costs more to build and is not right for most stores.
Updated August 2026
Most stores should not do this.
An honest account of what headless costs, before what it gives.
Powerful, more expensive, and wrong for most stores.
A normal Shopify store gives you the storefront and the backend together. Convenient, and constrained — you work within what the theme system allows, and the platform decides much of your page speed.
Headless splits them. Shopify keeps doing products, inventory, orders and payments. The storefront becomes your own application, so you control the speed, the design and the experience completely.
The cost is real: more to build, more to maintain, and things the theme used to handle now need building. Worth it at genuine scale or with unusual requirements. Not worth it because it sounds modern — and we will say so.
What we build.
A storefront in Next.js
Server-rendered and fast, with the commerce engine feeding it over API.
Your existing backend kept
Shopify, BigCommerce or similar continues doing products, orders and payments. No migration of the hard parts.
Checkout decided deliberately
Keeping the platform's checkout is usually right — it is battle-tested and PCI-compliant. We will say when it is not.
Content and commerce together
Editorial, lookbooks and products in one experience rather than a blog bolted beside a shop.
One catalogue, several channels
Web, mobile app, kiosk, marketplace — all reading the same source.
Speed as the reason it exists
If a headless build is not measurably faster, it has not earned the cost.
The features apps used to provide
Reviews, wishlists, bundles. Some rebuilt, some replaced by services. Scoped honestly upfront.
SEO handled carefully
The most common way headless goes wrong. Rendering, redirects and structured data planned from the start.
Standard, or headless.
An honest account, including the parts that argue against it. Most stores should stay standard.
| Standard storefront | Headless | |
|---|---|---|
| Build cost | Lower | Roughly double |
| Time to launch | 4–8 weeks | 3–5 months |
| Page speed ceiling | Platform decides much of it | Yours to control |
| Design freedom | Within the theme system | Complete |
| Ongoing maintenance | Platform handles most | You maintain the storefront |
| Apps from the marketplace | Install and go | Many need rebuilding |
| Feeding an app or kiosk too | Awkward | Same API, no extra work |
| Right for | Almost every store | High traffic, or rules themes cannot express |
Where we would use it.
Shopify build — standard storefront, because that was the right answer for the volume.
Online sales achieved on a standard build, not a headless one.
If speed is not costing you measurable revenue, headless will not pay for itself.
When headless earns its cost.
Speed is genuinely costing you money
High traffic where a second of load time has a measurable revenue effect.
Your merchandising is unusual
Bundles, configurators or pricing rules no theme can express without a pile of apps.
Several channels, one catalogue
Web plus app plus kiosk. Headless is genuinely the right shape for this.
Not for a store doing modest volume
The cost will not pay back. A well-built standard storefront is the better answer and we will recommend it.
How we work.
We check it is worth it
Traffic, current speed, and what the constraints actually cost you. Often the honest answer is that a standard build fixes it.
We map what the apps do
Every marketplace app in use, and what replaces it. This is where headless projects overrun.
We decide about checkout
Usually keep the platform's. Rebuilding checkout is the highest-risk part of any commerce project.
We build the storefront
In two-week blocks, on a link you can browse from the first fortnight.
We plan the SEO carefully
Redirects, rendering, structured data. Migrations lose rankings when this is treated as an afterthought.
We launch in stages
A slice of traffic first, watching revenue and speed, before everything moves.
What we build on.
Frequently asked.
6 questions answered. Still have one? Reach out.
Probably not, and that is the honest answer for most stores. It costs roughly double to build and adds ongoing maintenance you did not previously have. It earns that at high traffic where load time has a measurable revenue effect, or where your merchandising genuinely cannot be expressed in a theme. If neither is true, a well-built standard storefront will serve you better for less.