Headless E-Commerce-Plattformen

Prospekte listen dir hundert Features auf. Im Betrieb entscheiden ein paar wenige, ob du zufrieden bist.

Die API und ihre Dokumentation

Das Herzstück ist die Schnittstelle. Schau dir an, ob es sich um eine moderne API handelt und wie die Dokumentation aussieht. Lass deinen Entwickler (oder die Agentur, die den Auftrag bekommt) eine halbe Stunde in die Doku schauen, bevor du unterschreibst. Wenn sie stöhnen, hast du deine Antwort. Eine schlechte Doku kostet dich über die Laufzeit mehr als jede Lizenzgebühr.

Rate Limits und Performance

Viele Anbieter begrenzen, wie viele Anfragen deine Anwendung pro Sekunde an die API schicken darf. Das klingt nach einem Detail, bis der erste Aktionstag kommt und dein Frontend gegen die Grenze läuft. Frag konkret nach: Wie viele Requests sind erlaubt, und was kostet es, die Grenze anzuheben?

Produktdatenmodell

Wie flexibel lassen sich Produkte abbilden? Hast du Varianten (Größe, Farbe), Bundles, Staffelpreise, kundenindividuelle Preise im B2B? Ein System, das nur einfache Produkte kann, bringt dich in die Bredouille, sobald das Sortiment wächst. Prüf das mit deinen echten Produkten in der Demo, nicht mit dem Beispielkatalog des Anbieters.

Webhooks und Ereignisse

Dein Shop muss mit anderen Systemen reden: ERP, Warenwirtschaft, Versanddienstleister, Buchhaltung. Prüf, ob die Plattform Webhooks anbietet, also automatische Benachrichtigungen bei Ereignissen ("neue Bestellung", "Lagerbestand geändert"). Ohne diese musst du ständig aktiv abfragen, und das wird schnell fehleranfällig.

Mehrsprachigkeit und Mehrwährungsfähigkeit

Gerade in DACH mit Deutschland, Österreich und der Schweiz ist das kein Nice-to-have. Du brauchst mindestens Deutsch in verschiedenen Ausprägungen, Euro und Schweizer Franken, und je nach Zielgruppe weitere Sprachen. Schau, ob das im Kern eingebaut ist oder ob es nachträglich über Umwege gelöst werden muss.

Wer bedient das System hinterher?

Lass die Software in der Demo von der Person bedienen, die später damit arbeitet, nicht vom Chef und nicht vom Vertriebsmitarbeiter des Anbieters. Wenn deine Sachbearbeiterin ein Produkt anlegen soll und drei Menüs suchen muss, dann ist das nicht ihr Fehler, sondern der des Systems. Diese kleinen Reibungen summieren sich über Jahre.

Wie hängt das Frontend am Backend?

Frag ganz genau: Liefert der Anbieter ein fertiges Frontend mit, oder musst du das komplett selbst stellen? Manche Anbieter haben ein Starter-Frontend, das dir Wochen an Arbeit spart. Andere geben dir nur die API und wünschen viel Erfolg. Beides kann richtig sein, aber du musst wissen, was du bekommst, sonst platzt dein Budget.

Wie steht es um den Anbieter selbst?

Bei einem Headless-System bindest du dich fest an die API-Struktur des Anbieters. Wenn der Anbieter morgen den Betrieb einstellt oder seine Preise verdoppelt, sitzt du fest. Schau, wie lange es das Unternehmen gibt, wie es finanziert ist und ob es eine erkennbare Kundenbasis in DACH gibt. Ein Anbieter mit deutschsprachigem Support und Rechnung mit Umsatzsteuer erspart dir viel Ärger.

Exit vor dem Einstieg klären

Klär vor der Unterschrift, wie du wieder rauskommst. Kannst du deine Produktdaten, Kundendaten und Bestellhistorie in einem gängigen Format exportieren? Gehört dir dieser Export, oder musst du dafür extra zahlen? Ein Anbieter, der bei dieser Frage ausweicht, sagt dir alles, was du wissen musst.

Der Lizenzpreis ist bei Headless fast nie die größte Position. Rechne über die gesamte Laufzeit, nicht nur den ersten Monat.

Verbreitete Abrechnungsmodelle

Du triffst im Markt vor allem auf diese Muster: eine feste monatliche oder jährliche Grundgebühr, eine Staffelung nach API-Aufrufen oder Traffic, eine Beteiligung am Umsatz (ein Prozentsatz des über den Shop abgewickelten Volumens), oder eine Kombination aus Grundgebühr und variablem Anteil. Bei umsatzabhängigen Modellen wächst deine Rechnung genau dann, wenn du erfolgreich bist. Das kann fair sein, es kann dich aber auch überraschen. Rechne durch, was das Modell bei deinem erwarteten Umsatz in zwei Jahren kostet.

Die versteckten Positionen

Die eigentlichen Kosten sitzen woanders:

• Frontend-Entwicklung: Bei Headless baust oder beauftragst du das Frontend. Das ist ein Projektbudget, oft die größte Einzelposition.
• Laufende Wartung: Das selbstgebaute Frontend braucht Pflege. Sicherheitsupdates, Anpassungen, neue Funktionen. Plan dafür ein dauerhaftes Budget ein, nicht nur einmalige Kosten.
• Hosting des Frontends: Anders als beim Komplettsystem musst du dein Frontend oft selbst hosten. Das sind zusätzliche laufende Kosten.
• Schnittstellen: Jede Anbindung an ERP, Zahlungsanbieter oder Versand kann eigene Kosten oder Entwicklungsaufwand verursachen.
• Support-Stufen: Der Basissupport reicht oft nicht. Reaktionszeiten und Ansprechpartner kosten in höheren Stufen extra.

Mein Rat: Bau dir eine einfache Tabelle für drei Jahre. Einmalige Kosten oben, laufende Kosten pro Monat mal 36. Erst diese Summe ist vergleichbar. Ein System mit niedriger Lizenz und teurer Entwicklung kann am Ende teurer sein als das Umgekehrte.

Headless gewählt, obwohl ein Baukasten gereicht hätte

Der häufigste Fehler. Ein Betrieb liest, dass die großen Marken headless arbeiten, und will das auch. Dann steht ein Shop mit dreihundert Produkten auf einem System, das für ganz andere Größenordnungen gebaut ist, und die Entwicklungsrechnung frisst die Marge. Die Technik war nie das Problem, die Passung war es.

Die Agentur baut, keiner kann es warten

Eine Agentur baut ein schönes Frontend und ist dann weg. Ein Jahr später soll etwas geändert werden, und niemand versteht den Code. Die Agentur ist ausgelastet oder existiert nicht mehr. Sorg von Anfang an dafür, dass der Code dir gehört, dokumentiert ist und auf einer verbreiteten Technik basiert, für die du auch andere Entwickler findest.

API-Grenzen erst am Aktionstag entdeckt

Ein Betrieb plant eine große Rabattaktion, schaltet Werbung, und das Frontend läuft gegen die Rate Limits der API. Der Shop wird langsam oder fällt aus, genau im teuersten Moment. Solche Grenzen testet man vorher unter Last, nicht im Live-Betrieb.

Datenpflege unterschätzt

Das System kann alles, aber die Produktdaten sind schlecht gepflegt, weil das Anlegen umständlich ist. Fehlende Bilder, falsche Preise, veraltete Bestände. Ein technisch starkes System nützt nichts, wenn die tägliche Pflege so mühsam ist, dass sie liegen bleibt.

Zahlungsarten zu spät bedacht

Erst kurz vor dem Start fällt auf, dass die im DACH-Raum erwarteten Zahlungsarten (etwa Kauf auf Rechnung, gängige Wallets, Lastschrift) nicht sauber angebunden sind. Das ist Entwicklungsaufwand, den keiner eingeplant hat, und verzögert den Start.

Ich bin kein Anwalt, und das Folgende ersetzt keine Rechtsberatung. Aber ein paar Punkte musst du auf dem Schirm haben.

Datenschutz (DSGVO)

Dein Shop verarbeitet personenbezogene Daten. Prüf, wo die Daten des Anbieters gespeichert werden. Server innerhalb der EU sind unkomplizierter als solche außerhalb. Du brauchst einen Vertrag zur Auftragsverarbeitung (AV-Vertrag) mit dem Anbieter. Frag danach, bevor du unterschreibst, nicht danach.

Bei Headless ist eine Besonderheit wichtig: Weil du das Frontend selbst baust, bist du für die datenschutzkonforme Umsetzung im Frontend selbst verantwortlich. Cookie-Einwilligung, Einbindung von Tracking, Ladeverhalten externer Ressourcen: Das liegt bei dir, nicht beim Plattformanbieter.

Pflichtangaben im Shop

Impressum, Datenschutzerklärung, Widerrufsbelehrung, Preisangaben inklusive Umsatzsteuer, Versandkosten, klare Angabe des Grundpreises wo nötig: Diese Pflichten musst du im selbstgebauten Frontend umsetzen. Ein Standardsystem hätte dir viel davon vorgegeben. Bei Headless bist du in der Verantwortung, dass es korrekt erscheint.

Der Bestellprozess

Gerade in Deutschland gilt die Vorgabe zur eindeutig beschrifteten Bestell-Schaltfläche (etwa "zahlungspflichtig bestellen"). Weil du den Checkout selbst gestaltest, musst du selbst dafür sorgen, dass diese und ähnliche Vorgaben eingehalten werden. Lass das jemanden prüfen, der sich mit E-Commerce-Recht auskennt, bevor du live gehst.

Barrierefreiheit

Für bestimmte Anbieter und Angebote steigen die Anforderungen an digitale Barrierefreiheit. Ob und ab wann dich das betrifft, hängt von deinem Geschäft ab. Nimm das früh in die Frontend-Planung mit, denn nachträglich ist es aufwendiger als von Anfang an.

Schritt 1: Ehrlich prüfen, ob du Headless brauchst

Schreib auf, welche Ausspielkanäle du in zwei Jahren wirklich bedienst und ob du dauerhaft Entwicklungskapazität hast. Wenn beides klein ausfällt, prüf zuerst ein einfacheres Komplettsystem. Diese Frage ehrlich zu beantworten, spart dir eventuell den ganzen Rest.

Schritt 2: Anforderungen mit echten Daten formulieren

Nimm deine tatsächlichen Produkte, deine echten Preisregeln, deine bestehenden Systeme (ERP, Versand, Buchhaltung). Schreib auf, was das neue System damit können muss. Diese Liste ist dein Prüfstein, nicht der Prospekt des Anbieters.

Schritt 3: Zwei bis drei Kandidaten in die Demo

Mehr als drei bringt selten mehr Erkenntnis. Lass in jeder Demo dieselben Aufgaben mit deinen echten Daten durchführen: ein komplexes Produkt anlegen, eine Bestellung durchspielen, eine Schnittstelle ansehen. Immer dieselben Aufgaben, sonst vergleichst du Äpfel mit Birnen.

Schritt 4: Entwickler und Sachbearbeiter einbeziehen

Der Entwickler bewertet API und Doku, die Sachbearbeiterin bewertet die tägliche Bedienung. Beide Urteile zählen. Ein System, das nur eine von beiden Seiten überzeugt, wird im Betrieb Probleme machen.

Schritt 5: Drei-Jahres-Kosten rechnen

Bau die Tabelle: einmalige Frontend-Entwicklung, laufende Wartung, Hosting, Lizenz oder Umsatzanteil, Support-Stufe, Schnittstellen. Summe über 36 Monate. Erst diese Zahl vergleichst du zwischen den Kandidaten.

Schritt 6: Vertrag und Exit prüfen

Bevor du unterschreibst: Datenexport in gängigem Format, Eigentum am Frontend-Code, AV-Vertrag, Kündigungsfristen, Preisanpassungsklauseln. Lass einen Vertrag im Zweifel juristisch ansehen. Die paar hundert Euro dafür sind gut angelegt.

Schritt 7: Mit einem klar begrenzten Start beginnen

Geh nicht mit dem kompletten Sortiment und allen Kanälen zugleich live. Starte mit einem klaren Ausschnitt, sammle Erfahrung, prüf Performance und Bedienung im echten Betrieb. Dann skalierst du. So findest du Probleme, solange sie noch klein und billig zu beheben sind.