Headless Commerce für Startups: ein Leitfaden für Gründer

Headless Commerce ist ein Ansatz, bei dem der Storefront, den deine Kunden sehen, von der Engine getrennt wird, die Produkte, Warenkörbe und Zahlungen verarbeitet. Beide Hälften kommunizieren über APIs, statt in einer einzigen Codebasis zu stecken. Für ein Startup ist diese Trennung ein Tauschgeschäft: mehr Freiheit bei der Customer Experience gegen mehr bewegliche Teile, die du betreiben musst.

Dieser Leitfaden richtet sich an Gründer, die abwägen, ob sich der Tausch lohnt. Wir klären, was der Begriff wirklich meint, wie die Bausteine zusammenspielen, wie er gegen eine All-in-one-Plattform wie Shopify abschneidet und in welchen Fällen Headless dich eher ausbremst als beschleunigt. Am Ende weißt du, ob deine erste Version das überhaupt braucht und wie ein schlanker Build aussieht, falls doch.

Headless Commerce trennt das Frontend (den "Head") von der Commerce-Logik im Backend. Das Frontend ist alles, womit dein Kunde interagiert: ein Webshop, eine Mobile-App, ein Kiosk-Terminal, eine Smart-TV-App. Das Backend speichert Katalogdaten, berechnet Preise, verwaltet den Bestand und wickelt Bestellungen ab. Sie reden über REST- oder GraphQL-APIs miteinander, statt in ein einziges Template-System geschweißt zu sein.

Im klassischen Aufbau rendert das Backend die Seiten direkt. Änderst du das Checkout-Layout, bearbeitest du Dateien in genau dem System, das auch die Zahlungen abwickelt. Gehst du headless, ist das Frontend eine eigene Anwendung. Du kannst das komplette Erscheinungsbild neu bauen, ohne die Bestellverarbeitung anzufassen, oder dasselbe Backend gleichzeitig an drei verschiedene Frontends andocken.

In diesem Kontext taucht oft der Begriff "Composable Commerce" auf. Composable geht einen Schritt weiter: Statt einer Headless-Plattform setzt du dir Best-of-Breed-Dienste für Suche, Zahlungen, Content und Warenkorb zusammen, jeder für sich austauschbar. Headless ist die Architektur, Composable ist die Beschaffungsphilosophie, die darauf aufsetzt.

Eine Headless-Commerce-Architektur hat drei Schichten, die du getrennt voneinander betrachten kannst.

Die Präsentationsschicht ist dein Storefront, meist eine JavaScript-App mit einem Framework wie Next.js oder Nuxt. Sie rendert Seiten, hält die Warenkorb-UI und ruft APIs ab, um Daten zu laden. Weil sie eine eigenständige App ist, kannst du sie auf einer CDN-Edge für schnelle Ladezeiten hosten und nach eigenem Zeitplan deployen.

Die API-Schicht ist der Vertrag zwischen vorn und hinten. Über einen GraphQL-Endpunkt fragt der Storefront genau die Felder ab, die er braucht (Produktname, Preis, das erste Bild), und das in einer Anfrage. REST-Endpunkte erledigen dasselbe mit festen URLs pro Ressource. In dieser Schicht steckt der größte Teil deiner Integrationsarbeit und der größte Teil deiner Latenz, also verdient sie echte Aufmerksamkeit.

Die Backend-Schicht deckt Katalogverwaltung, Preisregeln, Bestand, Kundenkonten und die Bestellorchestrierung ab. In einem Composable-Aufbau ist diese Schicht selbst mehrere Dienste: ein Zahlungsabwickler wie Stripe, ein Suchdienst wie Algolia, ein Headless-CMS wie Sanity für redaktionelle Inhalte und eine Commerce-Engine, die Bestellungen zusammenführt. Jeder spricht seine eigene API, und dein Frontend oder eine schlanke Backend-for-Frontend-Schicht näht die Antworten zusammen.

Der praktische Effekt: Eine Preisänderung wandert vom Backend über die API zu jedem angeschlossenen Frontend, ohne dass der Shop neu deployt wird, während ein Redesign der Produktseite live geht, ohne dass jemand den Zahlungsfluss anrührt.

Eine monolithische Plattform bündelt Storefront, Admin, Katalog und Checkout in einem Produkt. Shopify, BigCommerce im klassischen Modus und WooCommerce sind die üblichen Beispiele. Du bekommst am Tag der Anmeldung einen funktionierenden Shop, und die Plattform kümmert sich um Updates, Sicherheits-Patches und Verfügbarkeit.

Headless tauscht diesen Komfort gegen Kontrolle. Die folgende Tabelle zeigt, wo sich welcher Ansatz auszahlt. Lies sie als Spektrum, nicht als Urteil: Die meisten Shops in der Frühphase gehören ans monolithische Ende, und nur ein kleiner Teil von ihnen braucht wirklich, was Headless bietet.

Geh headless, wenn das Storefront-Erlebnis selbst das Produkt ist. Baust du eine Marke, deren Einkaufsfluss ungewöhnlich ist (ein Konfigurator, ein Abo-Bundle-Baukasten, ein content-lastiger redaktioneller Shop), wird dir eine Theme-basierte Plattform im Weg stehen und Headless wird dich befreien. Es zahlt sich auch aus, wenn du aus einem Bestand über mehrere Kanäle verkaufst oder die Performance-Decke eines Monolithen gesprengt hast und Edge-Rendering und feingranulares Caching brauchst.

Lass es für deine erste Version, solange nichts davon zutrifft. Ein Startup, das die Nachfrage für einen kleinen Katalog testet, braucht kein Custom-Frontend, sondern Verkäufe und Feedback. Acht Wochen damit zu verbringen, einen Composable-Stack zu verkabeln, bevor du weißt, ob überhaupt jemand kauft, ist ein Klassiker, um Runway zu verbrennen. Dasselbe gilt für ein winziges Team ohne eigenen Frontend-Entwickler, denn Headless ohne Entwickler wird schnell zum festgefahrenen Projekt.

Es gibt einen Mittelweg, den man kennen sollte. Manche Teams fahren hybrid: einen Managed Checkout von Shopify oder BigCommerce, und nur die Seiten mit dem höchsten Traffic (die Startseite, ein Produktkonfigurator, eine Kampagnen-Landingpage) als Headless-Frontend neu gebaut. Du bekommst das maßgeschneiderte Erlebnis dort, wo es die Zahlen bewegt, und lässt die unspektakulären, regulierten Teile wie Zahlungen, Steuern und Betrugsprüfung auf einer Plattform, die sie längst gelöst hat. Das hält die Integrationsfläche klein und den Launch-Termin nah.

Ein nützlicher Test: Schreib die eine Sache auf, die dein Shop können muss und die ein Standard-Theme nicht hinbekommt. Kannst du sie klar benennen und ist sie geschäftskritisch, kommt Headless infrage. Lautet die ehrliche Antwort "schönere Animationen" oder "fühlt sich individueller an", bleib monolithisch und schau später wieder. Du kannst jederzeit auf Headless migrieren, sobald Traffic und Anforderungen es rechtfertigen, und viele Teams machen genau das als bewusste zweite Phase.

Die wenigsten Teams bauen ein Commerce-Backend von Grund auf. Sie wählen eine Headless-Commerce-Plattform, die APIs bereitstellt, und bauen dann ein Custom-Frontend dagegen.

Im Backend kannst du mit Shopifys Storefront API Shopifys Katalog, Checkout und Zahlungen behalten und nur den Storefront komplett ersetzen, der risikoärmste Einstieg. Commercetools ist eine schwerere, API-first konzipierte Engine für größere Kataloge und komplexe Preislogik. BigCommerce und das quelloffene Saleor liegen dazwischen und decken die meisten mittelgroßen Anforderungen ab. Bei Softwareprodukten, die Abos statt physischer Waren verkaufen, zeigt sich die Headless-Idee als Billing-Schicht wie Stripe Billing, die an ein Custom-Dashboard angedockt wird, statt als vollwertige Commerce-Engine.

Im Frontend ist Next.js die Standardwahl, wegen der Rendering-Optionen und des großen Bewerberpools; Nuxt deckt die Vue-Seite ab. Für Inhalte, die das Marketing ohne Deploy bearbeitet, koppelst du den Shop mit einem Headless-CMS wie Sanity oder Contentful. Suche und Merchandising kommen meist von Algolia oder Typesense.

Der Stack, für den du dich entscheidest, prägt dein Recruiting und deinen Zeitplan. Ein Build aus Shopify plus Next.js ist ausgetreten und schnell besetzbar. Ein maßgeschneiderter Aufbau aus Commercetools und Microservices ist mächtig und langsam, und in einem ersten Release hat er selten etwas verloren. Wenn du einen Partner suchst, der das für dich zusammensetzt und betreibt, baut unser Team für individuelle Softwareentwicklung solche Stacks zu festem Umfang und Budget.

Die meisten Texte über Headless Commerce gehen davon aus, dass du physische Waren verkaufst, aber das Muster passt auch zu Softwareprodukten. Ein SaaS-Geschäft braucht selten einen Katalog oder einen Versandprozess. Was es braucht, ist eine Möglichkeit, Tarife zu schnüren, wiederkehrende Zahlungen einzuziehen und das Produkt selbst auf die Aufgabe fokussiert zu halten, für die Nutzer es eingestellt haben. Headless Commerce für SaaS bedeutet meist, dass ein Billing-Dienst wie Stripe Billing oder Chargebee Abos, Trials und anteilige Abrechnung hinter einer API verwaltet, während deine App ihre eigenen Pricing- und Account-Screens rendert.

Diese Trennung bringt dir dasselbe wie einem Shop: Du kannst die Pricing-Seite ändern, ein Experiment zur Trial-Länge fahren oder den Billing-Anbieter wechseln, ohne das Produkt umzuschreiben. Die nutzerseitige App ruft die Billing-API für Tarifdaten und Berechtigungen ab, und ein Webhook meldet deinem Backend, wann eine Zahlung gelungen ist oder eine Karte abgelehnt wurde. Halte die Abo-Logik in der Billing-Schicht und das Feature-Gating in deiner App, dann kann sich jede Seite nach eigenem Zeitplan weiterentwickeln.

Wenn Gründer nach Headless-Commerce-Software suchen, wägen sie meist zwei Kategorien ab. Die eine ist die Commerce-Engine selbst (Shopify, Commercetools, Saleor), die Katalog und Checkout über eine API bereitstellt. Die andere ist das Drumherum: Billing-, Steuer-, Such- und Content-Systeme, die sich in diese Engine einklinken. Bei einem Softwareprodukt fällt die erste Kategorie oft ganz weg und die zweite leistet die eigentliche Arbeit. Wenn das Verkabeln dieser Bausteine nicht das ist, worauf dein Team seine Zeit verwenden soll, gibt es Dienstleister für Headless-Commerce-Entwicklung, die den Stack für dich zusammensetzen und betreiben, ein Weg, den viele Startups für ihr erstes Release wählen.

Ein Headless-MVP soll eine Sache beweisen: dass Kunden über das Erlebnis kaufen, das du nicht von der Stange bekommst. Alles andere bleibt bewusst langweilig.

Fang damit an, das Backend managed zu lassen. Nutze Shopify oder BigCommerce als Commerce-Engine, dann erbst du funktionierenden Checkout, Steuern und PCI-konforme Zahlungen, statt sie selbst zu bauen. Verbinde einen Next.js-Storefront über die Storefront API. Bau nur das eine differenzierende Feature ein, das den Schritt zu Headless überhaupt gerechtfertigt hat, und liefere den Rest als Standardseiten aus.

Verschieb den Composable-Wildwuchs. Du brauchst nicht am ersten Tag einen separaten Suchdienst, ein CMS und eine Bewertungsplattform. Füg jedes Stück erst hinzu, wenn ein echter Kundenbedarf auftaucht. Jede Integration, die du aufschiebst, ist eine Woche, die du zurückbekommst, und ein bewegliches Teil weniger, das du überwachen musst.

Miss ab dem Launch die Grundwerte: Conversion-Rate, Ladezeit auf dem Smartphone und Checkout-Abschluss. Diese Zahlen sagen dir, ob das Custom-Frontend wirklich besser abschneidet als ein Theme es geschafft hätte. Dahinter steckt dieselbe schlanke Philosophie wie bei unserem Ansatz zur schnellen MVP-Entwicklung, wo das Ziel ein funktionierender, verkaufsfähiger Shop in Wochen ist statt einer perfekten Plattform in Monaten. Wer das größere Commerce-Bild verstehen will, findet auf unserer Seite zu E-Commerce-Entwicklung, wie sich solche Builds in einen Launch-Plan einfügen.