Fixed scope
Fixed price
against a written scope
- Written scope and acceptance criteria up front
- Fixed price against that scope
- Staged delivery with review points
- Change requests priced separately, never absorbed silently
Shopify headless, when it is actually the answer
Hydrogen and Oxygen, or the Storefront API with your own framework. Headless buys you control over rendering, routing and composition — at the cost of owning infrastructure the platform used to hand you for free. We will tell you when that trade is worth making, including when it is not.
Most stores should not go headless
Headless is sold as a performance upgrade. It is really an architectural trade: you gain total control over the front end and take on rendering, caching, deployment, previews and a second codebase that Liquid gave you for nothing.
The honest test
Headless earns its cost when you need rendering Liquid cannot do — a genuinely app-like interface, content composed from several systems, a storefront serving more than one brand or channel from one codebase, or a front end your in-house engineers need to own in a framework they already work in.
It does not fix a slow store. A well-built Liquid theme with a disciplined app stack will out-perform a careless Hydrogen build, and cost a fraction to run.
See the trade-off
What you are taking on
Caching strategy, ISR or SSR decisions, preview environments, a deployment pipeline, error budgets and observability — none of which exist as your problem on a Liquid theme.
The theme editor also goes away. Merchandisers lose in-context editing unless you rebuild it, which is the single most underestimated cost of a headless migration and the reason some of them get quietly reversed.
Or build it in Liquid
The headless stack we build on
Shopify’s own headless primitives first. Nothing proprietary, nothing that traps you.
Hydrogen
Shopify’s React framework for custom storefronts, built on Remix — with the Shopify-specific caching and analytics already wired in.
Oxygen
Shopify’s global hosting for Hydrogen. Deploys, preview environments and edge rendering without you running infrastructure.
Storefront API
The GraphQL API underneath it all. If Hydrogen is not the right framework for your team, the same data is available to Next, Nuxt, Astro or anything else that speaks GraphQL — the decision is reversible.
Customer Account API
Login, orders, addresses and payment methods on a headless front end, using Shopify’s own authentication rather than a bespoke identity system you then have to secure.
Metaobjects
Structured content authored in Shopify and queried by the storefront, so editors are not sent to a separate CMS for every change.
Core Web Vitals
LCP under 2.5s, INP under 200ms, CLS under 0.1. Headless makes these achievable, not automatic.
What a headless build covers
Beyond the storefront itself, these are the pieces that decide whether it is maintainable.
Storefront application
Routing, rendering strategy, cart and checkout hand-off, search and filtering — built to be read by whoever maintains it next.
Content model
Metaobjects and metafields designed so editors work in Shopify, not in a spreadsheet handed to a developer.
Caching and rendering, decided deliberately
Which routes are static, which stream, which revalidate and how long anything is allowed to be stale. Get this wrong and headless is slower than the theme it replaced — this is where the performance actually comes from, not from React.
- Edge caching
- Streaming SSR
- Stale-while-revalidate
Editor experience, rebuilt on purpose
Going headless takes the theme editor away. We replace it deliberately — preview deployments, structured content in Shopify, and content surfaces your team can change without a pull request. Skipping this is how headless projects get reversed.
- Preview environments
- Structured content
- No developer for copy
Observability
Error tracking, real-user monitoring and alerting, because a headless storefront can fail in ways a theme cannot.
Handoff
Documented architecture and decisions, so your engineers can own it or another agency can pick it up.
Headless vs Liquid theme
This is the honest version. We build both, and we would rather talk you out of the wrong one now than rescue it later.
| Liquid theme | Headless storefront | |
|---|---|---|
| Build cost | Lower | Substantially higher |
| Running cost | Included in Shopify | Hosting, monitoring, maintenance |
| Ceiling on the front end | The theme architecture | Effectively none |
| Merchandiser editing | Native theme editor | Only what you build for them |
| App ecosystem | Everything works | Theme-app-extension apps mostly do not |
| Time to change copy | Minutes, in the editor | A deploy, unless you built for it |
| Performance ceiling | High if disciplined | Higher, if you get caching right |
| Best when | Almost every store | App-like UX, multi-brand, or an in-house front-end team |
How we work
How a headless build runs
7 stages. Open any one of them.
Should you do this at all
The stage where we sometimes say no.
We look at what you need the front end to do that Liquid cannot, and what your team can maintain. If a theme is the better answer we will say so before you have spent anything.
Rendering and data
The decisions that determine performance.
Framework choice, routes, rendering strategy per route, caching and revalidation, and the content model. Written down and agreed before any feature work.
UX and UI
Designed for the interactions headless unlocks.
If the interface is not doing something a theme could not, the architecture is not paying for itself. Design should reflect that.
Development
Deployed previews from week one.
Storefront application, content model and integrations, on preview deployments you can click through as they land.
Hardening
Including failure modes a theme does not have.
Cross-browser and device coverage, accessibility, Core Web Vitals on real routes, plus API failure, timeout and rate-limit behaviour.
Go live
With a way back.
Redirects, analytics, structured data, DNS cut-over and a rollback path — which on headless means a deployable previous version, verified before launch.
Ownership
Someone has to run this.
Framework and dependency updates, monitoring, and iteration. Either your engineers own it with our documentation, or we retain hours for it.
Ways to engage
Three shapes, depending on how well defined the work is. Every one starts with a scoped written proposal — no work begins on a verbal estimate.
Retainer
Monthly
block of hours
- A block of hours each month
- Prioritized by you, replanned as often as you like
- The same developers month to month
- Reporting on what the hours went to
Time & materials
Tracked time
billed as used
- Billed against tracked time
- Suits discovery, R&D and migrations
- Estimate per ticket before it starts
- Stop or change direction at any point
Rates are quoted against a written scope rather than published as a tier, because the same service costs very different amounts on a five-template store and a five-hundred-template one.
Context
The categories we build for
Headless suits some categories far more than others. If your product page is a product page, a theme is probably the answer.
Fashion & Apparel
Beauty & Cosmetics
Food & Beverage
Jewelry & Luxury
Home & Outdoor
Electronics
Health & Supplements
Subscription
Sports & Fitness
Multi-region
Marketplace & Multi-store
Questions about Shopify headless
Headless earns its cost when you need rendering Liquid cannot do — a genuinely app-like interface, content composed from several systems, one codebase serving multiple brands or channels, or a front end your in-house engineers need to own in a framework they already work in. It is an architectural trade rather than a performance upgrade: you gain total front-end control and take on caching, rendering, previews, deployment and observability.
Not by itself. Headless raises the performance ceiling; it does not raise the floor. A carelessly built Hydrogen storefront with bad caching is slower than a disciplined Liquid theme and costs far more to run. If speed is the only goal, start with a technical audit rather than a replatform.
Apps that work through theme app extensions or script tags generally do not carry over — that includes many reviews, upsell and popup apps. Apps with their own APIs usually do. Auditing your app stack is part of deciding whether headless is viable at all.
Only as far as you build for it. The native Shopify theme editor is not available on headless, so editor surfaces have to be rebuilt — preview deployments, structured content in Shopify metaobjects, and content your team can change without a pull request. Skipping this is the most common reason headless projects get reversed.
Hydrogen on Oxygen is the shortest path and the least infrastructure to own. If your engineers already work in another framework and will maintain it, the Shopify Storefront API is framework-agnostic — it works with Next, Nuxt, Astro or anything else that speaks GraphQL — and that may matter more than the head start.
Checkout stays on Shopify. That is not a limitation: it keeps PCI scope, fraud handling and payment methods someone else's problem. On Shopify Plus you can extend it with checkout extensibility and Shopify Functions.
It is easier to get wrong. Server rendering, canonical URLs, structured data, sitemaps and redirects become your responsibility rather than the platform's, so we treat them as build scope rather than a later pass.
More than a Shopify theme build, and it depends heavily on route count, content model and integrations. We scope first and quote against a written scope.
Yes, and it is worth knowing that before you start. Your products, content and checkout stay in Shopify throughout, so reverting means building a theme rather than migrating a platform. We keep that path open by not putting anything essential outside Shopify.
Not sure headless is the right call?
Good. Tell us what you need the storefront to do, and we will give you a straight answer on whether it needs headless or a better theme.