Shopify Headless Development
A storefront with
no theme ceiling.
Hydrogen, Remix and Next.js storefronts on the Storefront API — for the brands that genuinely need them, and an honest conversation for the ones that do not.
What this is
Headless Shopify, plainly.
Headless Shopify separates the storefront your customers see from Shopify’s commerce backend. Instead of rendering through Liquid themes, the frontend is a separate application — typically Hydrogen, Remix or Next.js — that reads products, collections, cart and checkout through the Storefront API. Shopify still owns catalogue, inventory, orders, payments and checkout. You are replacing the presentation layer, not the commerce engine.
Storefront architecture
The decisions made in week one determine whether the build is maintainable in year two.
- Hydrogen + Oxygen, Remix, or Next.js — chosen per project
- Storefront API data layer with typed queries
- Routing, rendering and caching strategy defined up front
- Cart and checkout handoff built properly, not approximated
- Preview and staging environments that mirror production
Content layer
The thing most headless builds forget until a marketer asks how to change a banner.
- Shopify metaobjects and metafields where they fit
- Headless CMS integration where they do not
- Editable sections and page composition for non-developers
- Preview before publish
- Content model designed with the people who will use it
Performance engineering
Headless is not automatically fast. It is fast when someone is accountable for a number.
- Core Web Vitals budget agreed before development
- LCP, INP and CLS measured in CI, not after launch
- Streaming and partial hydration where they earn their complexity
- Image, font and third-party script discipline
- Edge caching and revalidation strategy
Search & discovery
Catalogue navigation is where headless projects most often regress against the theme they replaced.
- Search, filtering and faceting architecture
- Collection and PLP performance at real catalogue size
- URL structure preserved or deliberately redirected
- Structured data emitted server-side
- Crawlability verified, not assumed
SEO continuity
A headless replatform is a migration. Treating it as a redesign is how brands lose rankings they never get back.
- Full URL inventory and redirect map before launch
- Server-rendered HTML for anything that must be indexed
- Product, Offer and Breadcrumb schema
- Canonicals, pagination and parameter handling
- Post-launch index and traffic monitoring
Handover & ownership
A headless storefront is a software product. It needs the things software needs.
- Documented architecture and deployment process
- CI, preview deploys and release workflow
- Error monitoring and alerting
- Dependency and framework upgrade plan
- Training for whoever maintains it next
The honest version
Most stores should not go headless.
Headless costs more to build and more to keep running, and a well-built Liquid theme is genuinely fast. We turn down more headless projects than we take. Here is the split we use.
The theme system is actually the limit
- Interaction or design the theme architecture genuinely cannot express
- One frontend serving several brands, regions or catalogues
- Commerce embedded in a larger application — a portal, a configurator, a member area
- Content and commerce that need to live in the same codebase
- An in-house engineering team who will own it after we leave
Things headless will not fix
- Speed — a bloated headless bundle is slower than a clean theme
- Conversion rate — that is a research and testing problem
- Wanting a more modern stack with no user-facing reason behind it
- A competitor doing it, without knowing why they did
- No team or budget to maintain an application after launch
Headless buys you freedom and charges you maintenance, forever. Take the trade knowingly.
How it runs
Prove the case, then build it.
The first stage exists to give you permission to stop. If the theme can do what you need, that is the cheaper answer and we will say so.
Feasibility & Case
What you need the storefront to do, whether a theme could do it, and what headless would cost to build and to run. Some of these end with a recommendation not to proceed.
Week 1Architecture
Framework, hosting, data layer, content model, caching and rendering strategy, plus the Core Web Vitals budget. Written down and agreed before anyone writes a component.
Week 1–3Build
Component library, templates, search and filtering, cart and checkout handoff, content integration. Performance measured continuously rather than audited at the end.
Week 3–12Migration & Launch
Redirect map executed, schema verified, analytics and feeds reconnected, indexing confirmed. Treated as a replatform, because that is what it is.
LaunchOperate
Monitoring, dependency upgrades, and a release process your team can run. Headless storefronts rot faster than themes when nobody owns them.
OngoingOur thinking, published
Headless, in more depth.
We have written about this more sceptically than most agencies do, because most headless projects we are asked to quote should not happen.
FAQ
Headless questions.
Headless Shopify separates the storefront your customers see from Shopify’s commerce backend. Instead of rendering through Liquid themes, the frontend is a separate application — typically Hydrogen, Remix or Next.js — that pulls products, cart and checkout through the Storefront API. Shopify still handles catalogue, orders, payments and checkout.
Most stores should not. Headless costs more to build and more to maintain, and a well-built Liquid theme is fast. It becomes worth it when you need design or interaction the theme system genuinely cannot express, when you serve several brands or markets from one frontend, or when content and commerce need to live in the same application. We will talk you out of it if the only reason is performance.
It can be, but not automatically. Headless removes theme and app-script overhead, and edge rendering helps. It also introduces new ways to be slow — oversized JavaScript bundles, waterfall API calls, poor caching. We hold headless builds to an explicit Core Web Vitals budget, because headless without a performance budget often ends up slower than the theme it replaced.
Theme-editor content editing, most storefront apps that work by injecting scripts, and a chunk of the plug-and-play Shopify ecosystem. Anything a marketer used to change in the theme editor now needs a CMS or a purpose-built component. That trade-off should be a decision, not a surprise after launch.
Hydrogen with Oxygen hosting when the project is commerce-first and the team wants to stay close to Shopify’s own tooling. Next.js when the storefront is part of a larger application or needs a content platform alongside it. We pick per project and explain why, rather than defaulting to whichever we used last.
Related services
Do you actually
need headless?
Tell us what the theme is stopping you doing. We’ll tell you whether headless is the answer, what it would cost to run, and when a custom theme would get you there for less.