Headless Commerce 2026: ein Entscheidungsrahmen für CTOs (und wo MedusaJS hineinpasst)

Headless Commerce ist lange genug die Standardantwort auf jede Architekturfrage gewesen, dass die interessante Frage nicht mehr was ist das lautet, sondern wann ist es falsch. Niemand im Ökosystem schreibt darüber, weil jeder im Ökosystem das Ja verkauft.

Wir bauen Headless-Storefronts auf MedusaJS — und wir belassen Kunden ebenso auf Magento oder Shopify, wenn das die bessere Antwort ist. Das ist der Rahmen, mit dem wir diese Situationen unterscheiden, und eine ehrliche Einordnung von Medusa.js unter den Alternativen.

Was Headless tatsächlich verändert

Ohne das Marketing bedeutet Headless: Commerce Engine und Storefront sind getrennte Anwendungen, die über eine API kommunizieren. Alles andere — Composable, MACH, API-first — ist eine Aussage darüber, wie weit diese Trennung reicht.

Was es Ihnen wirklich bringt:

• Freiheit im Frontend. Kein Theme-System, gegen das Sie ankämpfen, keine Template-Sprache, die Sie umgehen müssen.
• Mehrere Kanäle aus einem Backend. Web, App, Kiosk, Marktplatz und inzwischen Agenten-Schnittstellen, alle von derselben Commerce-Logik bedient.
• Unabhängiges Deployment. Die Storefront geht live, ohne dass die Commerce Engine angefasst wird, und umgekehrt.
• Austauschbare Komponenten. Suche, CMS oder Payment ersetzen, ohne die Plattform zu wechseln.

Was es Sie kostet — und diesen Teil lässt das Verkaufsgespräch aus:

• Zwei Anwendungen im Betrieb statt einer — getrenntes Hosting, getrennte Deployments, Monitoring, Abhängigkeits-Updates und Sicherheitspatches.
• Alles, was der Monolith kostenlos mitbrachte, neu gebaut: SEO-Ausgabe, Sitemaps, strukturierte Daten, Inhalte mit Vorschau, Redirects, Fehlerseiten.
• Ein Merchandising-Team, das selbst nichts mehr ändern kann, sofern Sie nicht bewusst für dieses Team mitbauen.
• Frontend-Entwicklung als dauerhafte Anforderung, nicht als Projekt bis zum Launch.

Die vier Anforderungen, die es rechtfertigen

Nach unserer Erfahrung muss einer dieser Punkte wirklich zutreffen. Nicht als Absicht — tatsächlich, in diesem Jahr.

1. Wirklich mehr als ein Frontend

Eine Web-Storefront plus native App, oder mehrere Marken-Storefronts, die sich einen Katalog und eine Bestellstrecke teilen, oder ein B2B-Portal neben einem D2C-Shop. Wenn es genau eine Storefront gibt und keinen finanzierten Plan für eine zweite, trifft die wichtigste Begründung für Headless auf Sie nicht zu.

2. Geschäftslogik, die die Plattform nicht abbilden kann

Preise, die von Vertragskonditionen abhängen, konfigurierbare Produkte mit echten technischen Randbedingungen, Prozesse vom Angebot bis zur Bestellung, Steuern über mehrere Gesellschaften hinweg, komplexes Fulfillment-Routing. Wenn Ihre Geschäftsregeln Ihr Wettbewerbsvorteil sind, dann kostet eine Plattform, die sie einschränkt, Sie in der falschen Währung.

3. Ein Frontend-Erlebnis, das selbst das Produkt ist

Konfiguratoren, geführter Verkauf, hohe Interaktivität, ein Erlebnis, das sich nach einer Anwendung anfühlen muss und nicht nach einem Katalog. Wenn Ihre Storefront Produkte zeigen und Zahlungen entgegennehmen soll, erledigt ein gutes Theme das schneller und günstiger.

4. Plattformkosten, die gekippt sind

Enterprise-Commerce-Lizenzen erreichen sechsstellige Jahresbeträge und skalieren mit Ihrem Wachstum statt mit Ihrer Nutzung. Ab einem gewissen Volumen finanziert allein dieser Posten ein Entwicklungsteam. Das ist ein realer und zunehmend häufiger Grund für einen Wechsel — und eine Finanzentscheidung, keine technische.

Wann wir Nein sagen

Aus diesen Gründen lehnen wir Headless-Projekte regelmäßig ab:

• Eine Storefront, konventioneller Katalog, übliche Geschäftsregeln. Shopify oder Magento dienen Ihnen besser und kosten weniger.
• Keine eigene Frontend-Kompetenz und kein Plan, sie aufzubauen. Sie sind dann für jede Inhaltsänderung dauerhaft von einer Agentur abhängig.
• Performance ist der Beweggrund. Eine langsame Website ist fast nie langsam, weil sie ein Monolith ist. Sie ist langsam wegen dessen, was auf ihr gebaut wurde — für Magento-Frontends haben wir das ausführlich dargelegt, und die Argumentation lässt sich übertragen.
• Das Team ist klein. Headless vervielfacht den Betriebsaufwand. Unterhalb einer bestimmten Teamgröße ist dieser Aufwand die gesamte Roadmap.
• Die Entscheidung fällt für den Lebenslauf. Wenig wohlwollend gesagt, aber es kommt vor. Eine Architektur, die aus Interesse statt aus Anforderungen gewählt wird, ist die teuerste Sorte.

Wo MedusaJS hineinpasst

Wenn der Entscheidungsrahmen Headless ergibt, lautet die nächste Frage: welche Engine. Medusa.js ist eine Commerce Engine auf Basis von Node.js und TypeScript — Open Source, modular, self-hosted betreibbar, mit einem offiziellen Next.js-Starter und einem gemanagten Cloud-Angebot.

Es passt gut, wenn:

• Ihr Team schreibt bereits TypeScript. Das ist das stärkste einzelne Argument. Die Commerce Engine läuft in derselben Sprache wie die Storefront, ein Team kann also an beidem arbeiten — und einstellen heißt hier Node-Entwickler einstellen, keine Spezialisten.
• Sie wollen die Commerce-Logik besitzen und verändern. Medusas Modulsystem ist auf Erweiterung ausgelegt, und Sie können in den Quellcode schauen, wenn Sie etwas überrascht.
• Lizenzkosten sind Teil des Beweggrunds. Keine Gebühr pro Bestellung, keine Umsatzbeteiligung.
• B2B steht im Zentrum. Firmenkonten, Angebote und Freigabeprozesse sind gut abgedeckt, und genau hier schlagen Open-Source-Engines SaaS-Plattformen am häufigsten.

Es passt schlecht, wenn:

• Sie brauchen ein großes Ökosystem an Drittanbieter-Apps. Shopifys App Store ist ein echter Vorteil, den keine Open-Source-Engine erreicht. Wenn Ihr Geschäft auf fertigen Integrationen läuft, wiegt das schwerer als die Architektur.
• Ihr Team arbeitet vor allem mit PHP. Ein Node-Backend einzuführen bedeutet Weiterbildung oder Neueinstellungen — reale Kosten, die in den Vergleich gehören.
• Ihnen ist die Verantwortung eines Anbieters am wichtigsten. Open Source heißt, das Betriebsrisiko liegt bei Ihnen. Medusa Cloud mildert das ab, beseitigt es aber nicht.
• Ihr Katalog ist riesig und Ihr Zeitplan kurz. Die Performance bei großen Katalogen sollten Sie früh an Ihren eigenen Daten prüfen, statt sie vorauszusetzen.

Der ehrliche Vergleich

Die realistische engere Auswahl für ein Headless-Projekt im Mittelstand oder im Enterprise-Umfeld:

• MedusaJS — Node/TypeScript, Open Source, modular, self-hosted oder gemanagt. Am besten, wenn Ihr Team in JavaScript zu Hause ist und Sie die Logik besitzen wollen.
• Commercetools — der etablierte Enterprise-Anbieter. Ausgereift, gut unterstützt und entsprechend bepreist. Am besten, wenn der Einkauf einen Anbieter in der Verantwortung sehen will und die Lizenz bei Ihrem Volumen tragbar ist.
• Saleor — Python/Django, GraphQL-first, Open Source. Am besten, wenn Ihr Team in Python zu Hause ist.
• Shopify Plus headless (Hydrogen) — behält App-Ökosystem und gemanagtes Backend und ersetzt nur die Storefront. Oft die pragmatische Antwort und durchweg zu selten erwogen, weil sie architektonisch nicht rein ist.
• Auf dem Monolith bleiben und das Frontend neu bauen. Die Option, die niemand in die engere Auswahl nimmt — und häufiger die richtige Antwort als alles Vorstehende.

Vergleichen Sie sie an den langweiligen Achsen: wofür Ihr Team einstellen kann, wie die Gesamtkosten über drei Jahre aussehen, wer verantwortlich ist, wenn nachts um 3 Uhr etwas ausfällt, und wie schnell Sie die Entscheidung zurücknehmen könnten. Feature-Matrizen gleichen sich an, diese vier Punkte nicht.

Die Reihenfolge einer Migration

Wenn Sie wechseln, tun Sie es nicht als Cutover. Das Muster, das funktioniert:

1. Belegen Sie die Engine an Ihrem echten Katalog, Ihren Preisregeln und Ihrem Bestellvolumen — ein Spike, kein Projekt.
2. Bauen Sie die neue Storefront zuerst gegen das alte Backend, sofern Ihre aktuelle Plattform eine brauchbare API hat. Sie entschärfen die sichtbare Hälfte, ohne den Commerce anzufassen.
3. Migrieren Sie einen Markt, eine Marke oder einen Kanal. Lernen Sie an etwas, das Sie zurückrollen könnten.
4. Ziehen Sie die Commerce Engine zuletzt um, wenn die Storefront stabil läuft und das Team den neuen Stack kennt.
5. Halten Sie das alte System noch monatelang lesbar. Bestellhistorie und Finanzabfragen enden nicht mit dem Cutover.

Die Mechanik der Migration — Redirects, Datenprüfung, Neuaufbau von Integrationen — ist weitgehend plattformunabhängig; unsere Replatforming-Checkliste mit 40 Punkten gilt nahezu unverändert.

Unsere MedusaJS-Leistungen und unser Medusa-Entwicklungsteam übernehmen diese Arbeit, und unsere übergreifende Beratung zur Plattformauswahl beantwortet die Frage davor — einschließlich der Fälle, in denen wir empfehlen, genau dort zu bleiben, wo Sie sind.

Gehen Sie den Entscheidungsrahmen mit uns durch

Nennen Sie uns Ihre Kanäle, Ihre Geschäftsregeln und die Sprachen Ihres Teams, und wir sagen Ihnen, ob Headless gerechtfertigt ist — und welche Engine, falls ja. Wir sagen bleiben Sie bei dem, was Sie haben öfter, als der Ruf dieses Entscheidungsrahmens vermuten lässt. Sprechen Sie mit unserem Team; wir antworten innerhalb eines Werktags.