Wann Me­du­sa die fal­sche Wahl ist

Me­du­sa ist ein her­vor­ra­gen­des Werk­zeug, und die meis­ten Shops, die es ein­set­zen wol­len, brau­chen es nicht. Wir bau­en selbst auf die­sem Stack, self-hos­ted auf Hetz­ner, mit Coo­li­fy und Do­cker – und ge­nau des­halb sa­gen wir Ent­schei­dern re­gel­mä­ßig, dass sie die Fin­ger da­von las­sen sol­len.

Das klingt ge­gen das ei­ge­ne In­ter­es­se, ist aber die ehr­li­che­re Be­ra­tung. Wer nur die Stär­ken ei­ner Tech­no­lo­gie ver­kauft, ver­kauft die In­ter­es­sen sei­nes Dienst­leis­ters mit. Die in­ter­es­san­te­re Fra­ge ist nicht, was Me­du­sa kann, son­dern wann Me­du­sa die fal­sche Wahl ist. Wer die­se Gren­ze sau­ber be­nennt, wird bei der Emp­feh­lung in die an­de­re Rich­tung ge­glaubt.

Der klars­te Fall ist der Stan­dard-B2C-Shop. Ein über­schau­ba­res Sor­ti­ment, ein Markt, ein Check­out, kei­ne Son­der­pro­zes­se. Sie wol­len Pro­duk­te ein­stel­len, Zah­lun­gen ent­ge­gen­neh­men und Be­stel­lun­gen ab­wi­ckeln. Für die­ses Pro­blem ist eine Ma­na­ged-Platt­form ge­baut, und sie löst es in Ta­gen statt in Wo­chen.

Me­du­sa gibt Ih­nen an die­ser Stel­le vor al­lem ei­nes: Kon­trol­le. Sie kön­nen je­des Mo­dul aus­tau­schen, je­den Work­flow selbst schrei­ben, jede In­te­gra­ti­on frei wäh­len. Nur nutzt ein Stan­dard-B2C-Shop von die­ser Kon­trol­le nichts. Sie zah­len ei­nen Ar­chi­tek­tur-Auf­preis für Frei­heits­gra­de, die in Ih­rem Ge­schäfts­mo­dell nie zum Tra­gen kom­men. Das ist das Kern­mus­ter von Head­less Over­en­gi­nee­ring – Sie kau­fen eine Com­po­sable-Ar­chi­tek­tur für ein Pro­blem, das kom­po­nier­bar gar nicht sein muss.

Der ehr­lichs­te Test ist ba­nal: Wenn Sie Ihre ge­sam­ten An­for­de­run­gen in den Stan­dard­funk­tio­nen ei­nes SaaS-Bau­kas­tens ab­bil­den kön­nen, ist der Bau­kas­ten die rich­ti­ge Wahl. Me­du­sa lohnt erst, wenn die An­for­de­run­gen die Gren­zen die­ses Bau­kas­tens spren­gen.

Der zwei­te Grund ge­gen Me­du­sa steht nicht im Fea­ture-Ver­gleich, son­dern in der Be­triebs­rea­li­tät. Ein Pro­duk­tiv-Stack braucht zwin­gend Post­greS­QL als Com­mer­ce-Store und Re­dis für Cache, Event Bus, Lo­cking und die Work­flow-En­gi­ne. Me­du­sa muss da­bei in zwei Modi lau­fen: ei­nem Ser­ver-Mo­dus für API und Ad­min und ei­nem Wor­ker-Mo­dus für Back­ground-Jobs, ge­steu­ert über ME­DU­SA_WOR­KER_MODE. Der of­fi­zi­el­le De­ploy­ment-Gui­de nennt als Mi­ni­mum 2 GB RAM und Node.js in ei­ner ak­tu­el­len LTS-Ver­si­on.

Das ist kei­ne exo­ti­sche An­for­de­rung, aber es ist ein Be­triebs­mo­dell. Je­mand muss die­se Kom­po­nen­ten patchen, über­wa­chen, si­chern und im Aus­fall wie­der hoch­brin­gen. Bei ei­nem Shop mit Um­satz ist Aus­fall kein Schön­heits­feh­ler, son­dern ver­lo­re­ner Ver­kauf. Be­triebs­kom­ple­xi­tät ist da­mit kein Ne­ben­ef­fekt, den man spä­ter löst, son­dern ein Kos­ten­pos­ten, der ab Tag eins läuft.

Für ein Team mit Ent­wick­lern und ei­ner Be­triebs­kul­tur ist die­ser Stack All­tag. Für ein Mar­ke­ting-Team ohne de­di­zier­te IT ist er eine Dau­er­last, die sich als Kon­trol­le tarnt. Wenn nie­mand bei Ih­nen ei­nen Re­dis-Neu­start um 23 Uhr ver­ant­wor­ten will, ist die Ant­wort auf die Make-or-Buy-Fra­ge be­reits ge­fal­len – und sie lau­tet Buy.

Der drit­te Grund ist das Bud­get, und hier liegt das häu­figs­te Miss­ver­ständ­nis. Me­du­sa ist Open Source und er­hebt selbst kei­ne Trans­ak­ti­ons- oder Um­satz­ge­bühr. "Kos­ten­los" be­zieht sich aber nur auf die MIT-li­zen­zier­te Soft­ware, nicht auf Be­trieb und Ent­wick­lung.

In der Pra­xis liegt eine sau­be­re Erst­im­ple­men­tie­rung ei­nes self-hos­ted Stacks ein­ma­lig bei 5.000 bis 20.000 €. Die rei­ne In­fra­struk­tur auf Hetz­ner star­tet güns­tig, ein AX41-Ser­ver kos­tet rund 39 bis 49 € im Mo­nat, ein ein­fa­cher Ein­stieg liegt bei etwa 20 bis 50 €. Der lau­fen­de Be­trieb schlägt mit 2 bis 5 Stun­den im Mo­nat zu Bu­che, bei ei­nem Misch­satz von rund 120 € pro Ent­wick­ler­stun­de. Das Drei-Jah­res-Ge­samt­bild ei­ner mit­tel­stän­di­schen App lan­det da­mit rea­lis­tisch bei 40.000 bis 80.000 €.

Die­se Zah­len sind für den rich­ti­gen An­wen­dungs­fall at­trak­tiv, weil die Kur­ve stimmt: Self-hos­ted-Kos­ten sin­ken über die Zeit, wäh­rend Ma­na­ged- und SaaS-Kos­ten mit dem Um­satz stei­gen – in­klu­si­ve Trans­ak­ti­ons­ge­büh­ren, so­bald ein Fremd-PSP im Spiel ist. Bei ei­nem klei­nen Sor­ti­ment mit klei­nem Um­satz kippt die­se Rech­nung aber. Der Break-even ge­gen eine SaaS-Platt­form kommt bei nied­ri­gem GMV schlicht nie. Sie tra­gen die Fix­kos­ten der Kon­trol­le, ohne je den va­ria­blen Vor­teil ein­zu­fah­ren, der sie recht­fer­tigt. Wer hier zu Me­du­sa greift, über­zahlt an Ar­chi­tek­tur.

Für die drei ge­nann­ten Fäl­le ist Shop­i­fy die prag­ma­ti­sche Me­du­sa Al­ter­na­ti­ve, und es lohnt sich, ein al­tes Ver­kaufs­ar­gu­ment zu be­er­di­gen. Seit dem 2. April 2026 sind die B2B-Grund­funk­tio­nen laut Shop­i­fys ei­ge­ner An­kün­di­gung auf al­len be­zahl­ten Plä­nen ver­füg­bar, nicht mehr Plus-ex­klu­siv: Com­pa­ny Pro­files, Net Terms, Vo­lu­me Pri­cing, bis zu drei ak­ti­ve Ca­ta­logs. "B2B läuft nur auf Plus" stimmt so nicht mehr. Das senkt die Ein­stiegs­hür­de für ein­fa­che B2B-Sze­na­ri­en er­heb­lich und ver­schiebt die Gren­ze, ab der man über­haupt über ei­nen Cus­tom-Stack nach­den­ken muss. Ob Shop­i­fy Plus mit sei­ner vier­stel­li­gen Mo­nats-Base-Fee die rich­ti­ge Stu­fe ist, hängt am Ein­zel­fall.

Der Preis die­ser Be­quem­lich­keit ist real, und er heißt Kon­trol­le. Der Shop­i­fy-Check­out ist eine ge­schlos­se­ne Black­box. Die freie An­pas­sung über check­out.li­quid ist für die Kern-Steps ab­ge­löst durch eine Ex­ten­si­on-Sand­box; ar­bi­tra­ry Ja­va­Script im Check­out ist nicht mehr vor­ge­se­hen. Auch auf Plus blei­ben Sie an das ge­bun­den, was Shop­i­fy Ih­nen an Er­wei­te­rungs­punk­ten zu­ge­steht. Das ist der klas­si­sche Trade-off: we­ni­ger Be­triebs­ver­ant­wor­tung ge­gen mehr Ven­dor-Lock-in. Für ei­nen Stan­dard-Shop ist die­ser Tausch fast im­mer rich­tig. Ge­nau des­halb ge­hört er ehr­lich auf den Tisch, statt hin­ter ei­nem Head­less-Ver­spre­chen zu ver­schwin­den. Wel­che Kun­den auf der an­de­ren Sei­te der Gren­ze ste­hen, ha­ben wir se­pa­rat sor­tiert: Head­less Com­mer­ce mit Me­du­sa – für wen.

Jetzt wird es ehr­lich kom­pli­ziert. Selbst wo Me­du­sa nach die­sen drei Kri­te­ri­en falsch wirkt – ein­fa­cher Ka­ta­log, klei­nes Team, klei­nes Bud­get – wür­de ich es in ei­ni­gen Fäl­len trotz­dem wäh­len. Die Kri­te­ri­en be­schrei­ben den Ist-Zu­stand, nicht den Zeit­ho­ri­zont.

Der häu­figs­te Bruch: Der "ein­fa­che Shop" bleibt sel­ten ein­fach. Er wächst in B2B-Pro­zes­se hin­ein, in Fir­men­kun­den mit Rol­len und Frei­ga­ben, in Spe­zi­al­prei­se, ir­gend­wann in ech­te Pro­cu­re­ment-An­for­de­run­gen. Und ge­nau dort en­det der be­que­me Pfad ab­rupt. Was En­ter­pri­se-Ein­kauf aus­macht – Pun­chout-Ka­ta­lo­ge, cXML oder OCI, Kos­ten­stel­len, Re­qui­si­ti­on-to-PO, Net-Terms-In­voi­cing ge­gen das ERP – lie­fert we­der ein SaaS-Bau­kas­ten schlüs­sel­fer­tig noch der Me­du­sa-B2B-Star­ter. Der Star­ter ist Re­fe­renz­code zum For­ken und Selbst­pfle­gen, kein ge­war­te­tes Pro­dukt­fea­ture; er bringt ein­fa­che Com­pa­ny-Ap­pr­ovals und Spen­ding Li­mits mit, aber nicht die ex­ter­ne ePro­cu­re­ment-An­bin­dung. Die­se Pro­cu­re­ment-Lü­cke ha­ben wir im De­tail zer­legt – sie ist bei bei­den We­gen vor­han­den, nur ist sie auf Me­du­sa über­haupt bau­bar.

Wenn ein sol­cher Pro­zess ab­seh­bar ist, zahlt der Shop­i­fy-Pfad spä­ter die Mi­gra­ti­on. Dann eine ge­schlos­se­ne Platt­form auf­zu­ge­ben und den Stack zu wech­seln, ist teu­rer und ris­kan­ter, als früh auf die aus­tausch­ba­re Ar­chi­tek­tur zu set­zen. Die­sel­be Lo­gik trägt bei Da­ten­ho­heit: Wer aus re­gu­la­to­ri­schen Grün­den Be­stel­lun­gen und PII in ei­ner selbst kon­trol­lier­ten Da­ten­bank in ei­nem EU-Re­chen­zen­trum hal­ten muss, hat mit ei­ner US-SaaS ein Sou­ve­rä­ni­täts­pro­blem, das kein Preis­ver­gleich auf­wiegt. Die Wet­te auf den Open-Source-Stack kann also auch klein und früh rich­tig sein. Sie ist eine Wet­te auf den ei­ge­nen Fahr­plan, kei­ne For­mel.

Be­han­deln Sie Me­du­sa nicht als State­ment, son­dern als In­ves­ti­ti­ons­ent­schei­dung mit ei­nem Zeit­ho­ri­zont. Zwei Fra­gen ent­schei­den fast al­les: Ha­ben Sie – in­tern oder über ei­nen ver­läss­li­chen Part­ner – die Kom­pe­tenz, ei­nen Stack aus Post­greS­QL, Re­dis und zwei Pro­zess­mo­di ver­ant­wort­lich zu be­trei­ben? Und rech­nen Sie in den nächs­ten zwei bis drei Jah­ren mit Son­der­pro­zes­sen, B2B-Kom­ple­xi­tät oder Da­ten-Ow­ner­ship, die eine SaaS-Platt­form nicht ab­bil­det?

Zwei­mal Nein, und Sie neh­men Shop­i­fy oder ei­nen Bau­kas­ten, sind schnel­ler live und schla­fen ru­hi­ger. Zwei­mal Ja, und die hö­he­re Be­triebs­kom­ple­xi­tät von Me­du­sa ist kein Nach­teil mehr, son­dern der Preis für Kon­trol­le, die Sie tat­säch­lich ein­lö­sen. Ein Ja und ein Nein – dann wird es eine ech­te Ab­wä­gung, und dann soll­ten Sie sie be­wusst tref­fen, statt sie ei­nem Tool-Trend oder ei­nem Dienst­leis­ter mit Lieb­lings-Stack zu über­las­sen. Die Ord­nung da­hin­ter, wel­che Ar­chi­tek­tur zu wel­chem Rei­fe­grad passt, ha­ben wir in un­se­rer Über­sicht zu Me­du­sa und Head­less Com­mer­ce aus­ge­führt. Wer die Gren­zen ei­ner Tech­no­lo­gie kennt, kauft nicht ih­ren Hype – er kauft eine Ent­schei­dung, die er vor dem CFO ver­tei­di­gen kann.