When Medusa Is the Wrong Choice

Medusa is an excellent tool, and most of the shops that want to use it do not need it. We build on this stack ourselves, self-hosted on Hetzner, with Coolify and Docker, and that is exactly why we regularly tell decision-makers to keep their hands off it.

That sounds against our own interest, but it is the more honest advice. Sell only a technology's strengths and you sell your vendor's interests along with it. The more interesting question is not what Medusa can do, but when Medusa is the wrong choice. Draw that line cleanly and you earn credibility when you point the other way.

The clearest case is the standard B2C shop. A manageable range, one market, one checkout, no special processes. You want to list products, take payments, and fulfil orders. A managed platform is built for exactly this problem, and it solves it in days rather than weeks.

What Medusa gives you here is mostly one thing: control. You can swap any module, write any workflow yourself, and pick any integration you like. A standard B2C shop gets nothing out of that control. You pay an architecture premium for degrees of freedom your business model never uses. That is the core pattern of headless overengineering: you buy a composable architecture for a problem that does not need to be composable at all.

The most honest test is almost trivial. If you can map every one of your requirements onto the standard functions of a SaaS builder, the builder is the right choice. Medusa only pays off once those requirements break through the builder's limits.

The second argument against Medusa lives not in the feature comparison but in the operating reality. A production stack needs PostgreSQL as the commerce store and Redis for cache, event bus, locking, and the workflow engine. Medusa has to run in two modes: a server mode for API and admin, and a worker mode for background jobs, controlled through MEDUSA_WORKER_MODE. The official deployment guide names 2 GB of RAM and a current Node.js LTS as the minimum.

None of that is exotic, but it is an operating model. Someone has to patch, monitor, back up, and recover these components when they fail. For a shop with revenue, downtime is not a cosmetic flaw but lost sales. Operational complexity is therefore not a side effect you handle later; it is a cost line that runs from day one.

For a team with developers and an operations culture, this stack is routine. For a marketing team with no dedicated IT, it is a standing liability dressed up as control. If nobody at your company wants to own a Redis restart at 11 p.m., the make-or-buy question has already answered itself, and the answer is buy.

The third argument is budget, and this is where the most common misunderstanding sits. Medusa is open source and charges no transaction or revenue fee of its own. But "free" refers only to the MIT-licensed software, not to operations and development.

In practice, a clean first implementation of a self-hosted stack runs a one-off 5,000 to 20,000 euros. The pure infrastructure on Hetzner starts cheap: an AX41 server costs roughly 39 to 49 euros a month, and a simple entry point sits around 20 to 50 euros (as of mid-2026, verify). Ongoing operations weigh in at 2 to 5 hours a month at a blended rate of around 120 euros per developer hour (estimate). Over three years, the total picture for a mid-sized app therefore lands realistically at 40,000 to 80,000 euros.

These numbers are attractive for the right use case, because the curve runs the right way: self-hosted costs fall over time, while managed and SaaS costs rise with revenue, including transaction fees the moment a third-party PSP is in play. With a small range and small revenue, the maths tips over. The break-even against a SaaS platform simply never arrives at low GMV. You carry the fixed cost of control without ever collecting the variable advantage that justifies it. Reach for Medusa here and you overpay in architecture.

For those three cases, Shopify is the pragmatic Medusa alternative, and it is worth burying an old sales argument along the way. Since 2 April 2026, according to Shopify's own announcement, core B2B features run on all paid plans and are no longer Plus-exclusive: company profiles, net terms, volume pricing, and up to three active catalogs. "B2B only runs on Plus" is no longer true. That lowers the entry barrier for simple B2B scenarios considerably and moves the line at which a custom stack even becomes worth considering. Whether Shopify Plus, with its four-figure monthly base fee, is the right tier depends on the individual case.

The price of that convenience is real, and its name is control. The Shopify checkout is a closed black box. Free customisation through checkout.liquid has been replaced, for the core steps, by an extension sandbox; arbitrary JavaScript in the checkout is no longer on offer. Even on Plus you stay bound to the extension points Shopify grants you. That is the classic trade-off: less operational responsibility in exchange for more vendor lock-in. For a standard shop this trade is almost always right, which is exactly why it belongs on the table honestly, rather than disappearing behind a headless promise. Which customers sit on the other side of that line, I have worked through separately, in a piece on who headless commerce with Medusa is actually for.

Here it gets genuinely complicated. Even where Medusa looks wrong by these three criteria, simple catalogue, small team, small budget, I would still choose it in some cases. The criteria describe the current state, not the time horizon.

The most common pattern: the "simple shop" rarely stays simple. It grows into B2B processes, into corporate customers with roles and approvals, into special pricing, and eventually into genuine procurement requirements. That is exactly where the comfortable path ends abruptly. What defines enterprise purchasing, punchout catalogues, cXML or OCI, cost centres, requisition-to-PO, net-terms invoicing against the ERP, is delivered turnkey by neither a SaaS builder nor the Medusa B2B starter. The starter is reference code you fork and maintain yourself, not a maintained product feature; it brings simple company approvals and spending limits, but not the external eProcurement connection. We have broken that procurement gap down in detail; it exists on both paths, but on Medusa it is at least buildable.

If such a process is foreseeable, the Shopify path means paying for a migration later. Abandoning a closed platform and switching stacks down the line is more expensive and riskier than betting early on the swappable architecture. The same logic holds for data sovereignty: anyone who must, for regulatory reasons, keep orders and PII in a self-controlled database in an EU data centre has a sovereignty problem with a US SaaS that no price comparison outweighs. The bet on the open-source stack can therefore be right even small and early. It is a bet on your own roadmap, not a formula.

Treat Medusa not as a creed but as an investment decision with a time horizon. Two questions decide almost everything. Do you have, internally or through a reliable partner, the competence to run a stack of PostgreSQL, Redis, and two process modes responsibly? And do you expect, over the next two to three years, special processes, B2B complexity, or data ownership that a SaaS platform cannot represent?

Two noes, and you take Shopify or a builder, go live faster, and sleep more soundly. Two yeses, and Medusa's higher operational complexity stops being a drawback and becomes the price for control you actually redeem. One yes and one no, and it turns into a genuine judgement call, one you should make deliberately rather than hand to a tool trend or a vendor with a favourite stack. The underlying order, which architecture suits which level of maturity, we set out in our overview of Medusa and headless commerce. Know the limits of a technology and you are not buying its hype; you are buying a decision you can defend in front of the CFO.