Shopify vs a Next.js Storefront: What You Actually Inherit
Shopify's fee buys a checkout, tax handling and an ops backend — not hosting. The four jobs you take on by leaving, the headless hybrid, and when owning the frontend pays.
Choose Shopify when selling is the business and the storefront is how you do it. Choose a Next.js storefront when the store is one surface of a product you already build, or when the shopping experience itself is the differentiator. For most people opening a store this year, Shopify is the right answer, and this page will tell you when it is not.
We sell Next.js storefront templates, so read the bias as declared. What follows is the comparison we would give a friend: what Shopify actually does for its cut, the four jobs you inherit the moment you leave it, the hybrid that most of this debate ignores, and the specific cases where owning the frontend pays for itself.
The decision in one table
| Axis | Shopify | Next.js storefront |
|---|---|---|
| Time to first sale | A weekend, from a theme | A week or two, from a template |
| Checkout | Built, PCI-compliant, conversion-tuned | You integrate a provider |
| Payments, tax, fraud | Handled | Handled by your provider, wired by you |
| Cost shape | Monthly plan + per-transaction % | Hosting + one-off template + your time |
| Design ceiling | High, inside Liquid and the theme editor | Whatever you can write |
| Frontend performance ceiling | Bounded by theme apps and scripts | You control every byte |
| Non-standard UX (configurators, 3D, quizzes) | An app, or a fight | Ordinary React |
| Who edits products and copy | Anyone, in the admin | Admin if headless; a developer if not |
| Inventory, orders, fulfilment | Built | You build or you integrate |
| Portability | Data exports; theme is Liquid | It is your repository |
Everything below is the detail behind a row.
What you are actually paying Shopify for
The instinct is to price Shopify against hosting. That comparison is wrong, and it is why people underestimate the switch.
Shopify's plan fee and transaction cut buy four things that have nothing to do with serving HTML:
- A checkout you did not build and cannot easily beat. It is PCI-scoped, tested against every payment method, and continuously optimised on conversion data from an enormous number of stores. Your first checkout will not be as good as theirs. Neither was ours.
- The money plumbing. Payment provider relationships, fraud analysis, chargeback handling, sales-tax calculation across jurisdictions, and the reporting an accountant asks for in year two.
- An operations backend. Orders, fulfilment, returns, inventory across locations, customer records, discount codes. This is the iceberg. Most "I'll just build a store" projects sink here, not on the product grid.
- An app ecosystem for reviews, subscriptions, loyalty, email, and shipping rates — features you would otherwise scope, build, and maintain.
If you are selling physical goods to consumers, that list is close to the entire job. A Next.js storefront replaces the part of the job that is a rendered page. It does not replace the rest, and any comparison that skips this is selling you something.
The comparison people actually make, and why it is rigged
The usual framing is "a Shopify theme, live this weekend" against "a custom Next.js build, three months and a five-figure invoice." Framed that way, Shopify wins every time, and the framing is doing all of the work.
The honest version compares like with like — a Shopify theme against a finished Next.js storefront template:
- Weekend one: Shopify still wins. You get products, checkout, and a domain live before Monday. A code template gets you the pages; you still have to wire a payment provider.
- Month three: the gap has closed on the frontend and opened on the backend. Your Next.js store looks exactly the way you designed it, and you are still writing order-status emails Shopify shipped with.
- Year two: the divergence is not build speed at all. It is whether the things you now want are inside your platform's box or outside it.
That third bullet is the actual question. "How fast can I launch" is answerable and mostly irrelevant. "What will I want in eighteen months" is unanswerable and decides everything.
The four jobs you inherit when you leave
Be specific about the work, because the surprise is what hurts:
Checkout and payments. Even with a hosted provider doing the heavy lifting, you own the redirect, the return, the success state, the signature-verified webhook, and the idempotency when that webhook fires twice. We wrote up the exact shape of this for a digital product in Selling a digital product from Next.js with LemonSqueezy — the checkout is the easy half; the webhook is where the bugs live.
Tax. If you sell physical goods across borders, tax is not a line of code, it is a subscription to a tax service plus a decision about who is the merchant of record. Some payment providers act as merchant of record and absorb this. Most do not. Find out which yours is before you write anything.
Inventory truth. A cart in a cookie can be wrong. Stock cannot. The moment two customers race for the last unit, you need a single authoritative store with a real transaction, not optimistic frontend state. This is the line where "no backend" stops being viable, and we say so plainly in the product variants post too.
Operations. Someone in the business needs to see orders, refund one, and reprint a label — at 9pm, on a phone, without a deploy. If your answer is "I'll build an admin," price that honestly: it is a second product.
The hybrid this debate keeps ignoring
The binary is false. The most common serious setup is Shopify headless: Shopify keeps products, inventory, orders and checkout, and a Next.js app renders the storefront against the Storefront API, handing off to Shopify's hosted checkout at the end.
You keep the operations backend and the checkout — the two hardest parts — and you take back the frontend, which is the part where design and performance live.
| Shopify themed | Shopify headless + Next.js | Fully own it | |
|---|---|---|---|
| Checkout | Shopify | Shopify | Yours to integrate |
| Ops backend | Shopify | Shopify | Yours to build |
| Frontend control | Theme-bounded | Total | Total |
| Plan + transaction fees | Yes | Yes | Provider fees only |
| Team needed | Merchandiser | Merchandiser + developer | Developer |
Headless is not free. You pay the platform fees and the engineering, you own two deploy surfaces, and preview/editing workflows get less pleasant for non-developers. But if your objection to Shopify is "the theme cannot express our brand" rather than "we do not want to pay Shopify," headless is the answer to the question you are actually asking.
Choose fully-owned when you are not selling standard retail goods at all: digital downloads, licences, seats, bookings, made-to-order work — cases where Shopify's object model fights you rather than helps you.
Where owning the frontend pays for itself
When the store is a surface of a product you already ship. If the app is Next.js and the store is Shopify, you maintain two design systems, two deploy pipelines, and a session that dies at a domain boundary in the middle of a purchase. One codebase removes an entire category of problem.
When the buying experience is the product. Configurators, fit finders, comparison tools, seat pickers, 3D or AR viewers, quizzes that produce a bundle. In a theme these are apps that inject scripts you did not write into a page you do not control. In React they are components.
When performance is a business metric you are held to. A Next.js storefront can be statically rendered with an image pipeline you control and a JavaScript budget you enforce. A Shopify theme's Core Web Vitals are substantially decided by which apps the marketing team installed, and you find out after they install them.
When you are doing serious technical SEO. Per-route canonicals, JSON-LD generated from your real catalogue data, a sitemap whose lastModified reflects actual content changes, and facet URLs you deliberately choose to index or not. All of these are code problems, and code is where they get solved cleanly. Both of those last two we have written up: Product schema in Next.js and why filters belong in the URL.
When your catalogue is small and your margins are thin. Twelve products, high volume, single market: the transaction percentage starts to look like a salary, and there is not much platform surface you are using to earn it.
Where we would tell you to stay on Shopify
Four cases, meant sincerely:
- You are validating, not scaling. Nobody has ever failed because their first store used a theme. They fail because nobody wanted the product. Find out cheaply.
- No developer on the team, and none coming. A storefront you cannot change is worse than a theme you can.
- Physical goods across multiple tax jurisdictions. The compliance surface is the whole iceberg, and platform fees are cheap next to getting it wrong.
- Your growth plan is operational, not experiential — more SKUs, more channels, more markets. That is exactly what Shopify's roadmap is for, and none of it is a frontend problem.
Mistakes we see in this decision
| Mistake | What happens | Better |
|---|---|---|
| Pricing Shopify against hosting | You budget for the wrong thing entirely | Price it against checkout + ops + tax |
| Comparing a theme to a from-scratch build | Launch speed looks decisive when it is not | Compare theme to template |
| Assuming "headless" means leaving Shopify | You reject the option that actually fits | Headless keeps checkout and ops |
| Building a custom checkout to save the fee | Months of work, then conversion drops | Use a hosted checkout either way |
| Ignoring who runs the store daily | Ops end up in the engineering queue | Decide who refunds an order at 9pm |
| Treating it as permanent | Paralysis over a reversible call | The catalogue is portable; the frontend is the cheap part |
Frequently asked questions
Is a Next.js storefront faster than Shopify? It has a higher ceiling and a lower floor. A statically rendered Next.js store with a controlled image pipeline will beat a typical theme, because you control every byte. A Shopify theme with five apps installed and a Next.js store nobody measured will land in the same place. Platform sets the ceiling; discipline decides where you sit under it.
Can I move from Shopify to Next.js later? Yes, and this is the standard migration path — usually via headless first, because it lets you replace the frontend without touching orders, inventory, or checkout. Keep your URL structure and redirect map deliberate and you will not lose rankings. Going the other way is also fine; product data exports cleanly.
What about Hydrogen, Shopify's own React framework? It is the officially-supported headless option, tightly integrated with Shopify's data and deployed on their infrastructure. Choose it if you want headless and you are certain you are staying on Shopify. Choose Next.js if the storefront needs to share code with a non-Shopify app, or if you want the deployment target to be your decision.
Do I need a backend at all for a small store? For a handful of fixed-price items, no — a static catalogue plus a hosted checkout works, and it is genuinely the cheapest thing that can work. You cross the line into needing one when stock has to be authoritative, when prices vary per customer, or when someone needs to look up an order.
Is WooCommerce, Medusa, or Saleor a third option? They sit on the same axis: WooCommerce trades Shopify's managed operations for WordPress-hosted ones, and Medusa and Saleor give you an open-source commerce backend you host, with the frontend left to you. Every one of them is a different answer to "who owns the operations backend" — which is the question this page is really about.
If the deciding factor was build time
Then re-run the argument from a real starting point, because "a Next.js store takes months" is a statement about starting from an empty directory.
Our storefront templates ship as complete, typed, statically-rendered stores. ASoc Kiln is a small-batch ceramics studio with five product categories, cart, wishlist and a class-booking section — the shape of a maker's store. ASoc Oak is a furniture store with seven categories, a furnish-a-room bundle with tiered savings, and countdown offers. ASoc Volt is a large-catalogue electronics store with browse-by-category navigation, featured-product tabs and hot-deals banners.
Browse the full set of Next.js shop templates, or the Tailwind shop templates if you would rather bring your own framework. If you are still weighing build-versus-buy more broadly, the honest cost breakdown has the numbers.