When Medusa Is the Wrong Choice

Medusa is an ex­cel­lent tool, and most of the shops that want to use it do not need it. We build on this stack our­selves, self-host­ed on Het­zn­er, with Coo­lify and Dock­er, and that is ex­act­ly why we reg­u­lar­ly tell de­ci­sion-mak­ers to keep their hands off it.

That sounds against our own in­ter­est, but it is the more hon­est ad­vice. Sell only a tech­nol­o­gy's strengths and you sell your ven­dor's in­ter­ests along with it. The more in­ter­est­ing ques­tion is not what Medusa can do, but when Medusa is the wrong choice. Draw that line clean­ly and you earn cred­i­bil­i­ty when you point the oth­er way.

The clear­est case is the stan­dard B2C shop. A man­age­able range, one mar­ket, one check­out, no spe­cial process­es. You want to list prod­ucts, take pay­ments, and ful­fil or­ders. A man­aged plat­form is built for ex­act­ly this prob­lem, and it solves it in days rather than weeks.

What Medusa gives you here is most­ly one thing: con­trol. You can swap any mod­ule, write any work­flow your­self, and pick any in­te­gra­tion you like. A stan­dard B2C shop gets noth­ing out of that con­trol. You pay an ar­chi­tec­ture pre­mi­um for de­grees of free­dom your busi­ness mod­el nev­er uses. That is the core pat­tern of head­less ov­erengi­neer­ing: you buy a com­pos­able ar­chi­tec­ture for a prob­lem that does not need to be com­pos­able at all.

The most hon­est test is al­most triv­ial. If you can map every one of your re­quire­ments onto the stan­dard func­tions of a SaaS builder, the builder is the right choice. Medusa only pays off once those re­quire­ments break through the builder's lim­its.

The sec­ond ar­gu­ment against Medusa lives not in the fea­ture com­par­i­son but in the op­er­at­ing re­al­i­ty. A pro­duc­tion stack needs Post­greSQL as the com­merce store and Re­dis for cache, event bus, lock­ing, and the work­flow en­gine. Medusa has to run in two modes: a serv­er mode for API and ad­min, and a work­er mode for back­ground jobs, con­trolled through MEDUSA_WORK­ER_MODE. The of­fi­cial de­ploy­ment guide names 2 GB of RAM and a cur­rent Node.js LTS as the min­i­mum.

None of that is ex­ot­ic, but it is an op­er­at­ing mod­el. Some­one has to patch, mon­i­tor, back up, and re­cov­er these com­po­nents when they fail. For a shop with rev­enue, down­time is not a cos­met­ic flaw but lost sales. Op­er­a­tional com­plex­i­ty is there­fore not a side ef­fect you han­dle lat­er; it is a cost line that runs from day one.

For a team with de­vel­op­ers and an op­er­a­tions cul­ture, this stack is rou­tine. For a mar­ket­ing team with no ded­i­cat­ed IT, it is a stand­ing li­a­bil­i­ty dressed up as con­trol. If no­body at your com­pa­ny wants to own a Re­dis restart at 11 p.m., the make-or-buy ques­tion has al­ready an­swered it­self, and the an­swer is buy.

The third ar­gu­ment is bud­get, and this is where the most com­mon mis­un­der­stand­ing sits. Medusa is open source and charges no trans­ac­tion or rev­enue fee of its own. But "free" refers only to the MIT-li­censed soft­ware, not to op­er­a­tions and de­vel­op­ment.

In prac­tice, a clean first im­ple­men­ta­tion of a self-host­ed stack runs a one-off 5,000 to 20,000 eu­ros. The pure in­fra­struc­ture on Het­zn­er starts cheap: an AX41 serv­er costs rough­ly 39 to 49 eu­ros a month, and a sim­ple en­try point sits around 20 to 50 eu­ros (as of mid-2026, ver­i­fy). On­go­ing op­er­a­tions weigh in at 2 to 5 hours a month at a blend­ed rate of around 120 eu­ros per de­vel­op­er hour (es­ti­mate). Over three years, the to­tal pic­ture for a mid-sized app there­fore lands re­al­is­ti­cal­ly at 40,000 to 80,000 eu­ros.

These num­bers are at­trac­tive for the right use case, be­cause the curve runs the right way: self-host­ed costs fall over time, while man­aged and SaaS costs rise with rev­enue, in­clud­ing trans­ac­tion fees the mo­ment a third-par­ty PSP is in play. With a small range and small rev­enue, the maths tips over. The break-even against a SaaS plat­form sim­ply nev­er ar­rives at low GMV. You car­ry the fixed cost of con­trol with­out ever col­lect­ing the vari­able ad­van­tage that jus­ti­fies it. Reach for Medusa here and you over­pay in ar­chi­tec­ture.

For those three cas­es, Shopi­fy is the prag­mat­ic Medusa al­ter­na­tive, and it is worth bury­ing an old sales ar­gu­ment along the way. Since 2 April 2026, ac­cord­ing to Shopi­fy's own an­nounce­ment, core B2B fea­tures run on all paid plans and are no longer Plus-ex­clu­sive: com­pa­ny pro­files, net terms, vol­ume pric­ing, and up to three ac­tive cat­a­logs. "B2B only runs on Plus" is no longer true. That low­ers the en­try bar­ri­er for sim­ple B2B sce­nar­ios con­sid­er­ably and moves the line at which a cus­tom stack even be­comes worth con­sid­er­ing. Whether Shopi­fy Plus, with its four-fig­ure month­ly base fee, is the right tier de­pends on the in­di­vid­ual case.

The price of that con­ve­nience is real, and its name is con­trol. The Shopi­fy check­out is a closed black box. Free cus­tomi­sa­tion through check­out.liq­uid has been re­placed, for the core steps, by an ex­ten­sion sand­box; ar­bi­trary JavaScript in the check­out is no longer on of­fer. Even on Plus you stay bound to the ex­ten­sion points Shopi­fy grants you. That is the clas­sic trade-off: less op­er­a­tional re­spon­si­bil­i­ty in ex­change for more ven­dor lock-in. For a stan­dard shop this trade is al­most al­ways right, which is ex­act­ly why it be­longs on the ta­ble hon­est­ly, rather than dis­ap­pear­ing be­hind a head­less promise. Which cus­tomers sit on the oth­er side of that line, I have worked through sep­a­rate­ly, in a piece on who head­less com­merce with Medusa is ac­tu­al­ly for.

Here it gets gen­uine­ly com­pli­cat­ed. Even where Medusa looks wrong by these three cri­te­ria, sim­ple cat­a­logue, small team, small bud­get, I would still choose it in some cas­es. The cri­te­ria de­scribe the cur­rent state, not the time hori­zon.

The most com­mon pat­tern: the "sim­ple shop" rarely stays sim­ple. It grows into B2B process­es, into cor­po­rate cus­tomers with roles and ap­provals, into spe­cial pric­ing, and even­tu­al­ly into gen­uine pro­cure­ment re­quire­ments. That is ex­act­ly where the com­fort­able path ends abrupt­ly. What de­fines en­ter­prise pur­chas­ing, pun­chout cat­a­logues, cXML or OCI, cost cen­tres, req­ui­si­tion-to-PO, net-terms in­voic­ing against the ERP, is de­liv­ered turnkey by nei­ther a SaaS builder nor the Medusa B2B starter. The starter is ref­er­ence code you fork and main­tain your­self, not a main­tained prod­uct fea­ture; it brings sim­ple com­pa­ny ap­provals and spend­ing lim­its, but not the ex­ter­nal ePro­cure­ment con­nec­tion. We have bro­ken that pro­cure­ment gap down in de­tail; it ex­ists on both paths, but on Medusa it is at least build­able.

If such a process is fore­see­able, the Shopi­fy path means pay­ing for a mi­gra­tion lat­er. Aban­don­ing a closed plat­form and switch­ing stacks down the line is more ex­pen­sive and riski­er than bet­ting ear­ly on the swap­pable ar­chi­tec­ture. The same log­ic holds for data sov­er­eign­ty: any­one who must, for reg­u­la­to­ry rea­sons, keep or­ders and PII in a self-con­trolled data­base in an EU data cen­tre has a sov­er­eign­ty prob­lem with a US SaaS that no price com­par­i­son out­weighs. The bet on the open-source stack can there­fore be right even small and ear­ly. It is a bet on your own roadmap, not a for­mu­la.

Treat Medusa not as a creed but as an in­vest­ment de­ci­sion with a time hori­zon. Two ques­tions de­cide al­most every­thing. Do you have, in­ter­nal­ly or through a re­li­able part­ner, the com­pe­tence to run a stack of Post­greSQL, Re­dis, and two process modes re­spon­si­bly? And do you ex­pect, over the next two to three years, spe­cial process­es, B2B com­plex­i­ty, or data own­er­ship that a SaaS plat­form can­not rep­re­sent?

Two noes, and you take Shopi­fy or a builder, go live faster, and sleep more sound­ly. Two yeses, and Medusa's high­er op­er­a­tional com­plex­i­ty stops be­ing a draw­back and be­comes the price for con­trol you ac­tu­al­ly re­deem. One yes and one no, and it turns into a gen­uine judge­ment call, one you should make de­lib­er­ate­ly rather than hand to a tool trend or a ven­dor with a favourite stack. The un­der­ly­ing or­der, which ar­chi­tec­ture suits which lev­el of ma­tu­ri­ty, we set out in our overview of Medusa and head­less com­merce. Know the lim­its of a tech­nol­o­gy and you are not buy­ing its hype; you are buy­ing a de­ci­sion you can de­fend in front of the CFO.