Shopify vs Next.js: Not the Choice It Looks Like

The framing of this question is wrong in a way that costs people money, so it is worth fixing before anything else.

Shopify and Next.js are not two ways to run a store. In nearly every version of this decision, Shopify stays: it keeps the products, the orders, the checkout, the payment compliance and the admin your team already knows. What is actually on the table is narrower and cheaper than it sounds - who renders the storefront.

What a headless storefront buys

Three things, and they are worth naming precisely because the marketing around this is vague.

Rendering you control. Which pages are static, which revalidate, which are dynamic, and what streams. A Liquid theme has one rendering model and you cannot change it. This is the whole of the model, and on a product page it is the difference between the image request starting in the HTML and starting after a script.

A front end that can be more than a store. Content, documentation, a configurator, a logged-in area, a design system shared with a product that is not the storefront. These are the projects where a theme becomes the wrong container.

A boundary against the app ecosystem. In a theme, every app you install puts script on your page and you carry the cost forever. Headless makes that an explicit decision each time rather than a default.

What it costs you

The theme editor. Merchandisers reordering sections without a developer is a real capability and it is the one most often waved away in the pitch. Some of it comes back through a CMS. Budget for that or expect a fight.

The apps. Anything that worked by injecting script into Liquid stops working. Reviews, upsells, banners, parts of your analytics. Each one is now a decision: re-implement against an API, replace, or drop on purpose. Make that list before the build rather than during it.

Checkout, mostly. Checkout stays on Shopify, which is the correct outcome and worth being clear about. You are not rebuilding the regulated part.

Hydrogen or Next.js, which is the real fork

Once you have decided to own the storefront, this is the actual choice.

Hydrogen is Shopify's own framework, built on Remix, with the Shopify assumptions already made and Oxygen to deploy it. If the storefront is only ever a storefront, it is a sensible default and there are fewer decisions in front of you.

Next.js earns its place when the site is more than the store. Marketing pages with their own rendering needs. Content that does not belong in Shopify. A design system shared with an application. A second data source. At that point Hydrogen's assumptions start costing rather than helping.

The traffic test, before any of this

Take the templates that carry your revenue. Usually the home page, one collection, one product page.

Measure them on field data, not a lab run. The causes are specific and short, and on a Shopify theme the answer is very often a hero image the browser finds late, a font blocking the paint, and four apps. All three are fixable in Liquid, in a week, for a fraction of a rebuild.

If the numbers are bad and the cause is the platform's rendering model rather than what has been bolted onto it, you have a real case. If the cause is three images, a rebuild will give you a fast site and you will never know whether you needed one.

When a theme is simply right

A store that is a store. A team with no front-end developer. A merchandising workflow that depends on the theme editor. A catalogue that changes more often than the code does.

We build headless storefronts and we will still say this: a well-maintained Liquid theme beats a headless storefront nobody owns, and the second one is what you get when the agency leaves and nothing was handed over. What a build actually includes is the part to ask about before signing anything, ours included.