Both Medusa and Shopify can sit behind a custom storefront. The storefront work, a Next.js app talking to a commerce API, looks almost the same either way. The real decision is about the backend: who runs it, what it costs as you scale, and how far you can bend its logic.
What each one is
The comparison that matters
| Kryeo | Shopify (headless) | |
|---|---|---|
| Who runs the backend | You do: deploy and operate Medusa yourself (or via a partner) | Shopify does: fully managed |
| Fees on revenue | None | Platform fee + revenue share on most plans; payment fees if not using Shopify Payments |
| Backend customisation | Unlimited; it is your codebase, with custom modules and workflows | Within Functions, apps, and API limits; core checkout logic is off-limits below Plus |
| Checkout control | Full: you build and own it | Shopify-hosted; customisable via Checkout Extensibility on Plus |
| Time to a first sale | Longer: the backend is set up and deployed | Faster: the backend already exists |
| Operational burden | You own uptime, scaling, and upgrades | Shopify owns infrastructure; you own your app and integrations |
| Ecosystem | Smaller; more is built in code | Large app marketplace; many needs are an install |
Cost, honestly
At low volume, Shopify is usually cheaper once you count engineering time. You get a running, scaling backend for a predictable monthly fee.
The crossover comes from the revenue share. On a store doing meaningful GMV, the percentage Shopify takes, plus the jump to Plus pricing, starts to exceed what it costs to run a Node service, a Postgres instance, and a Redis cache, even including the engineering to operate them. Past that point the Medusa line stays roughly flat while the Shopify line keeps climbing with revenue.
There is no universal number for the crossover; it depends on your margins, your plan, and how much custom engineering you'd do either way. But the shape is reliable: Shopify's cost scales with your success; self-hosted Medusa's does not.
Not sure which side of the line you're on?
Tell us your GMV, your plan, and what your checkout has to do. We'll give you a straight answer, including 'stay on Shopify' if that's it.
Ask us →When Shopify headless is the right call
- Your commerce logic fits Shopify's model: standard catalogue, standard checkout, standard fulfilment.
- You want someone else to own backend uptime and scaling.
- You rely on apps (reviews, subscriptions, loyalty, tax) that would be significant builds otherwise.
- You are not yet at the volume where the revenue share hurts.
When Medusa is the right call
- You need commerce logic Shopify can't express below Plus: custom pricing engines, unusual bundling, B2B quote-and-approve flows, made-to-order.
- The revenue share has become a real line item.
- You want the backend, the data, and the roadmap under your control, with no vendor able to change pricing or deprecate a feature you depend on.
- You have, or will hire, the engineering to operate it, or a partner who does.
The part that's the same either way
The storefront. With both, you build a custom front end, almost always Next.js, that fetches from a commerce API and renders product, collection, cart, and (for Medusa) checkout. You control rendering, metadata, structured data, and performance yourself. If your main goal is a custom storefront experience and your backend needs are standard, headless Shopify gets you there with less operational weight. If the backend is where your requirements live, that's where Medusa earns its cost.
A simple rule
Start with the backend question: does our commerce logic fit a platform's model, and is the revenue share acceptable at our size? If yes to both, headless Shopify. If no to either, Medusa. The storefront decision follows the same pattern regardless.
See our take on headless commerce and Medusa development for how we build each.