E-Commerce · Shopsysteme
Headless & Composable Commerce: Wann sich die Freiheit lohnt
Headless Commerce Vorteile und Nachteile: was die Freiheit wirklich kostet, Monolith vs. Composable im Vergleich – und ein klarer Entscheidungspfad.
Von Boaz Lichtenstein
„Headless“ ist eines der am meisten missverstandenen Wörter im E-Commerce. Es klingt nach Zukunft, wird aber oft ohne Blick auf die Kosten verkauft. Zeit für eine nüchterne Einordnung: Was heißt es technisch, was kostet es wirklich – und für wen lohnt sich der Schritt.
Das Wichtigste in Kürze
- Headless trennt Frontend und Backend über APIs; Composable kombiniert zusätzlich Best-of-Breed-Dienste statt einer All-in-one-Plattform.
- Die Freiheit hat einen Preis: Ohne eigenes oder verlässliches externes Dev-Team wird Composable schnell teurer als der Standard, den es ersetzen sollte.
- Composable lohnt sich vor allem bei mehreren Touchpoints, extremen Performance-Anforderungen oder sehr spezieller UX – nicht als Standardstart.
- Monolith-first bleibt für die meisten Händler die richtige Reihenfolge, gerade weil KI-gestützte Entwicklung Standard-Anpassungen heute günstiger macht.
- Die Total Cost of Ownership wird selten von Lizenzen bestimmt, sondern von der laufenden Integrationspflege zwischen den Diensten.
Was Headless und Composable technisch bedeuten
Headless trennt das Frontend (die Storefront, die Kund:innen sehen) vom Backend (Produktdaten, Warenkorb, Checkout-Logik); die Kommunikation läuft über APIs statt über ein festes Template-System. Composable geht einen Schritt weiter und ersetzt die All-in-one-Plattform durch eine Kombination einzeln ausgewählter Best-of-Breed-Dienste.
Konkret heißt das: Statt einer Plattform, die Suche, Content-Management und Checkout aus einer Hand liefert, kombinierst du Suche von Anbieter A, Content-Management von Anbieter B und Checkout von Anbieter C – jeweils über eigene Schnittstellen verbunden. Das Ergebnis ist maximale Flexibilität, aber auch maximale Eigenverantwortung für das Zusammenspiel der Teile. Jeder zusätzliche Dienst ist ein zusätzlicher Vertrag, eine zusätzliche API-Version, ein zusätzlicher Punkt, an dem etwas ausfallen kann.
Monolith vs. Composable im Vergleich
Die beiden Architekturen unterscheiden sich nicht graduell, sondern grundsätzlich in Team-Anforderung, Zeithorizont und Risikoprofil:
| Kriterium | Monolith | Composable |
|---|---|---|
| Time-to-Market | Wochen | Meist mehrere Monate |
| Team-Anforderung | Standard-Agentur reicht meist | Eigenes oder sehr erfahrenes externes Dev-Team nötig |
| Flexibilität | Begrenzt auf Plattform-Grenzen | Sehr hoch, aber selbst zu orchestrieren |
| Laufende Kosten | Planbar (Lizenz plus Wartung) | Variabel, dominiert von Integrationspflege |
| Ausfallrisiko | Ein Anbieter, ein Support-Kanal | Mehrere Anbieter, geteilte Verantwortung |
Keine Zeile dieser Tabelle macht eine der beiden Architekturen per se besser – sie zeigt nur, wofür jede gebaut ist. Auffällig ist vor allem die letzte Zeile: Beim Monolithen ist das Ausfallrisiko konzentriert, aber klar adressierbar – ein Anbieter, ein Vertrag, ein Eskalationsweg. Bei Composable ist es verteilt, aber dafür auch schwerer zu managen, weil im Ernstfall mehrere Verträge, mehrere Support-Zeiten und mehrere Eskalationswege gleichzeitig koordiniert werden müssen.
Der ehrliche Preis
Was in Verkaufspräsentationen gerne untergeht: Mit Headless übernimmst du die Verantwortung, die eine monolithische Plattform dir vorher abgenommen hat. Das Frontend muss jemand bauen und pflegen, jede Integration muss jemand warten, und bei Fehlern gibt es keinen einzelnen Support-Kanal mehr, sondern mehrere Anbieter, die sich gegenseitig die Schuld zuschieben können.
Die Faustregel ist deshalb einfach: Ohne eigenes Dev-Team – intern oder als verlässlicher externer Partner – ist Composable keine gute Idee. Die Freiheit ist real, aber sie hat einen Preis in Personentagen, nicht nur in Lizenzgebühren. Wer die Total Cost of Ownership realistisch kalkulieren will, sollte diese Personentage genauso einpreisen wie die Lizenzkosten der einzelnen Dienste – mehr zur Kalkulationslogik im Artikel zu Unit Economics im E-Commerce.
Ein typisches Ausfallszenario macht das Risiko greifbar: Der Such-Dienst eines Drittanbieters ändert ohne große Ankündigung ein API-Antwortformat, das Checkout-System meldet parallel eine Wartungslücke, und die eigene Storefront zeigt in der Zwischenzeit Produkte ohne aktuelle Preise an. Bei einer monolithischen Plattform wäre das ein einziger Support-Fall. Bei Composable sind es potenziell zwei Tickets bei zwei Anbietern, deren Zuständigkeit sich erst klären muss, während der Shop live weiterläuft.
Die häufigsten Fehler beim Umstieg
Fünf Muster tauchen bei gescheiterten oder überteuerten Composable-Projekten immer wieder auf:
- Migration ohne vorherigen Team-Aufbau starten: Erst das Projekt beauftragen, dann nach Entwickler:innen suchen – die Reihenfolge sollte umgekehrt sein.
- Zu viele Dienste auf einmal einführen: Suche, Content, Checkout und Personalisierung gleichzeitig austauschen statt schrittweise – das multipliziert das Risiko statt es zu verteilen.
- Keinen Owner für die Orchestrierung benennen: Wenn niemand explizit für das Zusammenspiel der Dienste verantwortlich ist, bleibt jeder Fehler im Niemandsland zwischen den Anbietern hängen.
- Performance-Versprechen ungeprüft übernehmen: „Headless ist schneller“ stimmt nur bei sauberer Umsetzung – siehe FAQ.
- SEO- und Content-Migration unterschätzen: URL-Struktur, Redirects und Rendering-Strategie brauchen einen eigenen Migrationsplan, keinen Nebensatz im Projektplan.
Wann es sich rechnet
Composable rechnet sich, wenn der Standard nachweislich an seine Grenzen stößt – nicht schon dann, wenn er unbequem wird. Drei Signale sprechen für den Wechsel: mehrere Touchpoints wie App, Web und In-Store-Kiosk, die dieselben Produktdaten in Echtzeit brauchen; extreme Performance-Anforderungen, bei denen jede Zehntelsekunde Ladezeit Umsatz kostet (siehe unser Artikel zu Page Performance und Conversion); oder sehr spezielle UX-Anforderungen, die kein Standard-Theme abbildet. Umgekehrt spricht gegen den Wechsel: ein kleines oder mittleres Team ohne dedizierte Entwicklungsressourcen, ein Sortiment ohne komplexe Multi-Channel-Anforderungen, oder ein Standard-System, das bislang nur „irgendwie eng“ wirkt, ohne dass eine konkrete Anforderung daran scheitert. In all diesen Fällen kauft Composable Freiheitsgrade, die ein Monolith strukturell nicht bietet – aber nur, wenn diese Freiheitsgrade auch tatsächlich gebraucht werden.
Der hybride Zwischenweg
Zwischen reinem Monolith und vollem Composable-Stack existiert inzwischen ein dritter Weg: Viele etablierte Plattformen bieten heute native Headless-APIs oder Composable-Erweiterungen an, die sich gezielt zuschalten lassen, ohne das gesamte Backend zu ersetzen. Das senkt die Einstiegshürde erheblich, weil ein Teil der Plattform-Sicherheit erhalten bleibt.
Konkret heißt das: Ein Händler kann etwa den Checkout und das Bestandsmanagement auf der bestehenden Plattform belassen, aber gezielt einen headless Frontend-Layer für die Produktseiten einführen – etwa für eine besonders schnelle Landingpage-Kampagne oder eine neue App. Dieser Zwischenweg ist selten das Endziel einer Composable-Reise, aber oft der klügste erste Schritt: Er zeigt, ob das Team die zusätzliche Komplexität tatsächlich verkraftet, bevor die gesamte Architektur zur Disposition steht.
Wichtig ist dabei, den hybriden Ansatz bewusst als Lernphase zu behandeln, nicht als Dauerzustand. Wer dauerhaft zwischen zwei Architekturen pendelt, sammelt technische Schulden auf beiden Seiten, statt eine davon konsequent zu beherrschen – der Zwischenweg soll eine Brücke sein, kein neues Zuhause.
Der Entscheidungspfad
Für die meisten Händler bleibt Monolith-first die richtige Reihenfolge – und diese Wahl trifft man heute anders als noch vor wenigen Jahren, denn KI-gestützte Entwicklung relativiert auch hier vieles: Wie schon im Vergleich Shopware vs. Shopify beschrieben, sinken die Kosten für individuelle Anpassungen an Standard-Systemen deutlich, was den Druck Richtung Composable verringert. Composable ist ein Verdienst, den man sich erarbeitet, sobald der Standard nachweislich zu eng wird – nicht der Startpunkt für ein neues Geschäft. Wer mit einem Monolithen beginnt und die Architektur bewusst modular hält, kann später gezielt einzelne Bausteine austauschen, statt am ersten Tag alles selbst zusammenbauen zu müssen.
Unterm Strich
Headless ist kein Statussymbol, sondern eine Architekturentscheidung mit klaren Kosten und klarem Nutzen. Wer die Frage „Haben wir das Team, das diese Freiheit trägt?“ ehrlich beantwortet, trifft die richtige Wahl fast von allein – unabhängig davon, was gerade als Trend gilt. Der pragmatischste nächste Schritt für die meisten Shops: mit dem bestehenden Monolithen so lange arbeiten, bis eine konkrete Anforderung nachweislich daran scheitert, statt aus Prinzip zu wechseln.