
Medusa vs. Shopify: Was KI-gestützte Entwicklung verändert
Ein praxisnaher Vergleich von Code-Ownership, Checkout-Flexibilität, Betriebsaufwand und Gesamtkosten.
Shopify ist für viele Commerce-Projekte zu Recht die naheliegende Wahl. Ein Shop geht schnell online, die Kernplattform wird betrieben und das App-Ökosystem deckt viele übliche Anforderungen ab. Ich habe Shopify-Shops gebaut und betreut, auch mit eigenem Headless-Frontend. Dieser Nutzen ist real.
KI-gestützte Entwicklung verändert den Vergleich, macht individuelle Software aber nicht kostenlos. Coding-Agenten verkürzen die Zeit für Analyse, Umsetzung und Änderungen. Sie übernehmen weder die Verantwortung für Architektur und Sicherheit noch für Updates, Backups oder einen defekten Checkout um zwei Uhr morgens. Genau dort sollte ein sinnvoller Vergleich von Medusa und Shopify beginnen.
Shopify passt weiterhin zu Teams, die eine verwaltete Plattform und weitgehend standardisierte Commerce-Abläufe wollen. Medusa wird interessanter, wenn das Geschäft eigene Workflows, ungewöhnliche Datenmodelle oder tiefe Integrationen braucht und das Team den Betrieb übernehmen kann.
Medusa und Shopify im direkten Vergleich
| Entscheidung | Shopify | Medusa |
|---|---|---|
| Start und Betrieb | Gehosteter Kern, ein großer Teil der Infrastruktur wird übernommen | Das Team stellt das Commerce-Backend bereit, überwacht, sichert und aktualisiert es |
| Checkout und Backend-Logik | Anpassbar über unterstützte Erweiterungspunkte und innerhalb der Grenzen des jeweiligen Tarifs | Eigene Module und Workflows liegen in der Anwendung |
| Datenmodell | Standardressourcen, erweitert durch Metafields, Metaobjects und Apps | Eigene Anwendungsmodelle und PostgreSQL in der üblichen Architektur |
| Zugriff für Coding-Agenten | Agenten ändern Theme-, Storefront- und App-Code, aber nicht Shopifys Plattformkern | Agenten können Storefront, Commerce-Logik und Datenmodell im eigenen Code nachvollziehen |
| Kostenprofil | Plattformtarif, Apps, mögliche Transaktionskosten und Entwicklung | Infrastruktur, Monitoring, Wartung und Entwicklung |
Keine der beiden Spalten ist grundsätzlich günstiger. Entscheidend ist, welche Arbeit eine Plattform übernehmen soll und welche Arbeit so geschäftsspezifisch ist, dass sie ins eigene System gehört.
Was Coding-Agenten tatsächlich verändern
Ein Coding-Agent arbeitet am besten, wenn er eine Anforderung durch das gesamte System verfolgen kann. In einem eigenen Stack findet er das Produktmodell, die Preislogik und die API, ändert die Storefront und ergänzt die Migration im selben Arbeitskontext. Ein Mensch muss die Anforderung weiterhin präzisieren und das Ergebnis prüfen. Es geht aber weniger Zeit dafür verloren, dieselbe Änderung über voneinander getrennte Werkzeuge hinweg zu übersetzen.
Shopify ist keine vollständig verschlossene Blackbox. Checkout UI Extensions ergänzen Oberfläche und Logik an unterstützten Punkten im Checkout. Shopify Functions passen Teile des Backend-Verhaltens an. Metaobjects erweitern das System um wiederverwendbare strukturierte Daten. Das sind umfangreiche Möglichkeiten.
Sie bleiben Verträge mit der Plattform. Ein Agent kann den öffentlichen Vertrag und die eigene Implementierung lesen, aber nicht den Vertrag selbst ändern. Einige Checkout-Erweiterungen setzen Shopify Plus voraus, Functions laufen innerhalb definierter APIs und Ressourcenlimits, und Integrationen mit der Admin API müssen Shopifys Abfrage- und Ressourcenlimits berücksichtigen. Das ist kein Fehler. Es ist der Tausch dafür, dass Shopify die Plattform betreibt.
Bei Medusa ist der Tausch umgekehrt. Die Commerce-Module stellen Domänenservices und Datenmodelle bereit, die eigene Workflows direkt nutzen können. Die Standardarchitektur bringt APIs, Workflows, Module und Datenspeicher in eine Anwendung, die das Team selbst betreibt. Ein Coding-Agent hat dadurch mehr Arbeitsfläche. Der Bereitschaftsdienst allerdings auch.
Der Stack, den ich gerade einsetze
Ich entwickle derzeit eine europäische Commerce-Plattform für sechs Märkte und einen Katalog mit mehreren Hunderttausend Produkten. Sie braucht marktspezifische Inhalte, eigene Preisregeln, regulierte Anzeigewerte und tiefe Integrationen. Diese Anforderungen lassen sich in einem eigenen Modell sauberer abbilden als verteilt über Plattformkonfiguration und mehrere Apps.
Der Arbeitsstack besteht aus Medusa für Commerce, Payload für redaktionelle Inhalte, Next.js für die Storefront, PostgreSQL für dauerhafte Daten und Typesense als leseoptimierte Suchprojektion. Payload unterstützt Live Preview und Datenbank-Migrationen, während Commerce-Anpassungen bei Medusa in Modulen und Workflows liegen.
Das Projekt läuft noch. Es ist keine abgeschlossene Studie zu den Gesamtkosten. Meine frühere Arbeit an der Sonnenglas-Plattform zeigt den betrieblichen Kontext: Die schwierigen Stellen im Multi-Market-Commerce liegen meist an den Übergängen zwischen Checkout, Content, Integrationen und Marktregeln. KI hilft mir, diese Übergänge schneller zu bearbeiten. Sie beseitigt sie nicht.
Die Architektur für 30-Tage-Tiefstpreise ist ein konkretes Beispiel. Wenn Preishistorie, Aktionszustand und Storefront-Projektion demselben technischen Modell folgen, lässt sich eine regulierte Preisangabe durchgängig nachvollziehen und testen. Mit Shopify kann dasselbe Ergebnis möglich sein, die Umsetzung muss jedoch zu Datenmodell und Erweiterungspunkten der Plattform passen.
Vor der Entscheidung den Betriebsaufwand zählen
Wer den Stack besitzt, besitzt auch seine Ausfälle. Ein realistischer Vergleich umfasst:
- Sicherheitsupdates und Abhängigkeitsaktualisierungen;
- Monitoring, Alarmierung, Backups und Wiederherstellungstests;
- Integrationen für Zahlungen, Steuern, Versand und Betrugsprävention;
- konsistente Daten in Bestellungen, Bestand und Suche;
- Releases und Störungsbehebung.
Coding-Agenten können bei jedem Punkt helfen. Sie können für keinen davon verantwortlich sein. Wenn im Team niemand eine Migration prüfen oder einen fehlerhaften Zahlungsablauf untersuchen kann, ist der betriebene Kern von Shopify viel wert.
Headless Shopify liegt dazwischen. Es passt, wenn die Storefront ein eigenes Erlebnis braucht, Produkte, Bestellungen und Checkout aber nah an Shopifys Modell bleiben können. Es passt schlecht, wenn fast jeder Punkt der Roadmap eine Umgehung von Backend-Grenzen erfordert. Dann betreibt das Team ein eigenes Frontend und entwirft trotzdem um eine Plattformgrenze herum.
Eine brauchbare Entscheidungsregel
Shopify passt, wenn ein schneller Start, ein erprobter Checkout, ein großes App-Ökosystem und wenig Betriebsverantwortung wichtiger sind als unbegrenzte Kontrolle über das Backend.
Medusa passt, wenn das Commerce-Verhalten selbst das Geschäft unterscheidet, Integrationen ungewöhnlich sind, sich das Datenmodell weiterentwickeln muss und das Team den Betrieb übernehmen kann.
KI-gestützte Entwicklung verschiebt den Punkt, ab dem die zweite Option wirtschaftlich wird. Sie trifft die Architekturentscheidung nicht. Wähle ein Modell mit Grenzen, die zum Geschäft passen, und einem Betriebsaufwand, den das Team wirklich tragen kann.
Quellen und weiterführende Dokumentation
Quellen geprüft am 1. August 2026.
Stehst du vor einer schwierigen Plattformentscheidung?
Beschreib mir, was das System leisten muss. Ich helfe dabei, aus den Anforderungen eine klare Architektur und einen umsetzbaren nächsten Schritt zu machen.
Projekt besprechen