Headless Shopify with Next.js is the right call for a few stores and an expensive mistake for most. The real reasons, the costs nobody lists, a checklist, and a hybrid that gets the best of both.
Headless comes up in almost every conversation with a Shopify merchant who has outgrown their theme. The pitch is seductive: your own front end, any framework, any design, no Liquid. Sometimes it is exactly right. More often it is an expensive way to rebuild what the theme already did, and the bill arrives a year later in the form of apps that no longer work and a checkout nobody can change.
This post is for a founder or e-commerce manager trying to decide. It covers what headless actually means on Shopify, the handful of reasons that justify it, the costs that never make the proposal deck, and a hybrid arrangement that gets most of the benefit for a fraction of the risk.
What headless means on Shopify, in one paragraph
A standard Shopify store renders its pages from a theme: Liquid templates, hosted and served by Shopify. A headless store keeps Shopify as the back office (products, inventory, orders, customers, checkout) and replaces the theme with a front end you host yourself, typically built in Next.js or Hydrogen, pulling data through the Storefront API. Checkout stays on Shopify in both cases. That last point matters, because it means the part of the store that handles money is the one part you cannot make headless anyway.
The real reasons to go headless
In our experience there are four situations where a custom front end earns its keep. If none of them describes your store, stop reading here and keep the theme.
- Content-heavy pages that a theme fights you on. Long-form guides, comparison tables, editorial layouts, glossaries with hundreds of entries. Liquid sections can do a surprising amount, but once the content has its own structure and its own editorial workflow, a framework with proper components and a real content model is simply faster to build and maintain.
- Pages driven by live data. A jewellery store publishing daily gold and silver rates, a calculator that prices a piece from weight and purity, a stock or delivery-time lookup. These need scheduled data fetches, server-side rendering with revalidation, and caching rules a theme cannot express.
- Performance at real scale. A very large catalogue with heavy filtering, or a store where a few hundred milliseconds of page load has been measured to matter, benefits from edge caching, streaming and image pipelines you control. Note the word measured. Most stores have not measured it.
- Multi-region and multi-language done properly. Shopify Markets handles a lot now. But if you need different page structures per region, different content per market, or a routing scheme a theme cannot follow, a custom front end gives you the control.
Notice what is not on the list: 'the theme looks dated', 'we want a unique design', or 'our agency recommends it'. A dated theme is a design job. A unique design is achievable in a theme. An agency recommendation is worth exactly what it costs the agency if it goes wrong, which is nothing.
The costs that never make the proposal
Every headless proposal we have seen lists the build cost. Almost none list the following, and together they are usually larger.
- Apps that stop working. A large share of Shopify apps do their job by injecting into the theme: reviews, upsells, size guides, wishlists, bundles, loyalty widgets, back-in-stock forms. In a headless build, every one of those either has an API you now integrate by hand, or it simply does not exist on your storefront any more. Make the list before you sign anything. It is usually longer than expected.
- Checkout. It stays on Shopify's domain, which means the shopper crosses from your front end to Shopify at the most sensitive moment of the visit. Checkout extensibility lets you customise it, but the transition has to be designed, tested on a phone on a slow connection, and kept consistent with the front end's design every time either side changes.
- Two deploy pipelines. The theme was hosted for you. Now you have a Next.js app on Vercel or similar, environment variables, preview deployments, a build that can fail at 11pm, and monitoring that someone has to watch. This is ordinary engineering, but it is engineering the theme did not require.
- Maintenance nobody budgets. Storefront API versions are deprecated on a schedule. Framework major versions arrive. The person who built it moves on. A theme store has a maintenance floor of roughly zero; a headless store has one measured in developer-days per quarter, forever.
- Analytics and pixels. Shopify's native reporting assumes the theme. Your web pixels, GA4, Meta and any first-party engagement tracking need to be wired into the new front end and verified event by event, or your merchandising data quietly goes blank the week you launch.
- Everything the merchant used to do alone. Adding a section, moving a banner, changing a homepage image at 9pm before a sale: these were theme-editor jobs. Unless the new front end has a proper CMS with a preview, they become developer tickets, and the business slows down in a way that never appears on a cost sheet.
Add these up honestly before comparing quotes. In our experience the build is a third to a half of the true three-year cost of going headless; the rest is the app replacements, the retained developer and the slower content operation. A proposal that shows only the first number is not wrong, exactly, but it is not the number you will pay.
A decision checklist
Answer honestly. Each 'yes' is a point in favour of headless; the costs above are the counterweight.
- Do we have at least one page type that genuinely cannot be built in the theme, and can we name it?
- Have we measured page speed and its effect on conversion, or do we just assume it is bad?
- Have we listed every installed app and checked which ones have a usable API?
- Is there a developer, in-house or on retainer, who will still be maintaining this in two years?
- Does the content team have a CMS with preview, so they are not blocked on engineers?
- Have we priced the checkout transition and tested it on a phone on a slow connection?
- Will the front end own its own analytics from day one, with events verified against Shopify's order data?
If the answer to most of these is no, the honest recommendation is a better theme, not a new architecture.
The hybrid: headless where it pays, theme where it does not
The arrangement we recommend most often is not a choice between the two. It is a split. The shop (collections, product pages, cart, checkout) stays on the Shopify theme, where every app works and the merchant keeps the theme editor. The content that justifies headless (rate pages, calculators, guides, campaign landing pages, anything editorial or data-driven) lives on a Next.js application served under the same brand.
This gets almost all of the upside. The data-driven pages get proper server rendering, scheduled revalidation and structured content. The shop keeps its apps, its analytics and its familiar admin. And the risk is contained: if the Next.js side breaks, people can still buy.
How the hybrid is wired
- Routing. The simplest version is a subdomain (for example rates.yourbrand.com) pointed at the Next.js app. A subpath on the main domain (yourbrand.com/gold-rate) looks cleaner and keeps authority on one host, but needs a reverse proxy in front of Shopify, which is more work and worth it only for content that is central to search.
- Shared chrome. Header, footer and navigation should look identical on both sides. In practice this means building them once in the front end and mirroring the theme's markup and menu structure, then agreeing that menu changes happen in both places or through one shared data source such as a metaobject.
- Cart handoff. Content pages link to products and collections on the theme. Where a page needs 'add to cart' directly, use the Storefront API to create a cart and hand the shopper to Shopify's checkout URL; do not rebuild the cart drawer twice.
- Content model. Keep the editable content in Shopify metaobjects or a small CMS, not in code. The rate page's FAQ, the guide's body, the campaign copy: an editor should change these without a deploy.
- Canonicals and sitemaps. Each side owns its own URLs. Submit both sitemaps, keep canonicals pointing at the served URL, and never let the two sides publish the same page.
- Measurement. Put the same first-party events on both sides, with a shared identifier, so a visit that starts on a rate page and ends in a theme checkout is one journey in your data, not two.
What we would tell a founder
Go fully headless if you can name the page types that require it, you have measured the performance problem, and you have a developer who will still be there in two years. Otherwise buy a good theme and spend the difference on photography and merchandising, which in our experience move revenue more reliably than architecture ever has.
And if you sit in between, which most growing brands do, build the hybrid. At LeelaRam Technologies this is the shape of most of the storefront work we take on: a headless Next.js layer for the pages that need it, a well-kept Shopify theme for the shop, and one set of measurement across both. It is less exciting than a full rebuild, and it is the version that is still running smoothly three years later.
