Eine bestehende Plattform bremst irgendwann das Geschäft. Marketing wartet auf freie Entwicklungskapazität, der Checkout hängt an einem monolithischen Release-Zyklus, und jede Konversion, die dabei verloren geht, bleibt lange unbemerkt. Genau hier setzen wir mit Headless-Commerce-Architekturen an: Wir entkoppeln das Frontend von der Commerce-Plattform, damit Teams schneller ausliefern und die Konversion steigt.

Wenn der Checkout ein Release braucht

Der Schmerz beginnt für viele IT-Teams an einer konkreten Stelle: Eine kleine Änderung am Checkout durchläuft dieselbe schwere Pipeline wie ein Großumbau, unabhängig davon, wie klein sie eigentlich ist. Wir entkoppeln das Frontend genau deshalb von der Plattform, damit Checkout-Änderungen einen eigenen, leichten Weg ins Produktivsystem bekommen.

Wenn Marketing auf Engineering-Tickets wartet

Ein zweiter Engpass bremst parallel dazu die Marketing-Seite: Die Warteschlange vor dem nächsten Sprint entscheidet über das Tempo einer Kampagne. Dein Content-Team verliert dadurch genau die Reaktionsgeschwindigkeit, die eine Saison oder eine Aktion oft braucht. Mit einer separaten Content-Ebene lösen wir dieses Team aus der Abhängigkeit von Entwicklungsressourcen.

Entkoppeltes Frontend

Das entkoppelte Frontend bildet den Kern der Architektur. Es läuft auf Frameworks wie Next.js oder Nuxt und spricht die Commerce-Plattform ausschließlich über APIs an, während die Rendering-Strategie je nach Seitentyp unterschiedlich ausfällt: Produktseiten profitieren von anderen Regeln als eine Startseite oder eine Kampagnenlandingpage. Mit dieser Trennung machen wir das Frontend zu einer eigenständigen Einheit, die unabhängig von der Plattform weiterentwickelt und ausgeliefert wird.

Commerce-API-Schicht

Wir legen eine Commerce-API-Schicht über die Plattform und stellen darüber Katalogdaten, Preise, Lagerbestände und die Auftragsverwaltung über REST- und GraphQL-Endpunkte bereit. Das Frontend fragt darüber genau die Daten ab, die eine Seite braucht, nicht mehr und nicht weniger. Das bedeutet für Entscheider in der IT: Änderungen am Frontend berühren die Kernsysteme nicht mehr direkt.

Content-Management ohne Code-Deployment

Separate Systeme wie Contentful oder Storyblok kommen für die Inhalte zum Einsatz. Dein Marketing-Team pflegt Texte, Bilder und Kampagnenseiten darin direkt selbst und veröffentlicht sie ohne Umweg über die Entwickler-Pipeline. Genau diese Unabhängigkeit von Engineering-Kapazität war der Auslöser für den zweiten Schmerzpunkt weiter oben, und sie ist der direkte Nutzen einer separaten Content-Ebene.

Composable: Best-of-Breed-Komponenten

Composable bedeutet, einzelne Best-of-Breed-Komponenten nur dort einzusetzen, wo sie der Plattform-Funktion überlegen sind, etwa Algolia für die Suche. Jede Komponente wird einzeln bewertet, nicht pauschal ausgetauscht.

Performance Engineering

Mit serverseitigem Rendering, Bildoptimierung und Edge-Caching legen wir gemeinsam fest, wie schnell eine Seite lädt und wie viele Besucher den Checkout überhaupt erreichen. Bei Detlev Louis brachte genau diese Kombination eine um 40 Prozent schnellere Seitenladezeit.

Mehr Komplexität, mehr Disziplin

Eine verteilte Architektur bringt mehr bewegliche Teile mit sich als eine klassische Plattform. Vom Frontend über die API-Schicht bis zum Content-System braucht jede Komponente eine eigene Deployment-Pipeline – das verlangt Disziplin, sonst wächst die Zahl der Systeme schneller als der Nutzen. Sinnvoll wird der Schritt dort, wo die Plattform-Limitierungen bereits dokumentiert sind und sich in Umsatz oder Time-to-Market niederschlagen.

Detlev Louis: Reibungslose Migration

Detlev Louis, Europas größter Anbieter rund um Motorräder und ihre Ausstattung, stieß mit der bestehenden Plattform an Grenzen: Weitere Skalierung verlangte zunehmend Behelfslösungen, und die internationale Expansion war in der nötigen Geschwindigkeit nicht mehr möglich. Wir begleiten die digitale Entwicklung von Detlev Louis seit 2018 und übernahmen die Migration der umsatzkritischen Plattform auf Spryker – der Betrieb lief durchgehend weiter, und die fünf Jahre an Kundendaten blieben vollständig erhalten.

Was während der Migration stabil blieb

Die über Jahrzehnte aufgebauten Suchmaschinenplatzierungen blieben während der Migration stabil, ein Risiko, das bei einem solchen Plattformwechsel sonst häufig eintritt. Entwickelt wurden eigene Performance- und SEO-Module sowie eine internationale Onlineshop-Architektur, die sich schnell und wiederholbar auf neue Länder ausrollen lässt. Die konkreten Ergebnisse hält der Kasten neben diesem Abschnitt fest.

Schuhe.de: Composable in der Praxis

Schuhe.de, die digitale Plattform der größten europäischen Handelsgenossenschaft im Nicht-Lebensmittelbereich, zeigt dieselbe Architektur in einer anderen Ausprägung. Wir entwickelten das Frontend mit Next.js und React neu. Als Commerce-API-Schicht setzten wir commercetools ein, das Produktdatenmanagement läuft über Akeneo, und für die Suche sorgt eine KI-gestützte Lösung von Algolia. Neue Funktionen und saisonale Kampagnen kommen seither deutlich schneller zustande, weil wir mit der modularen Architektur und automatisierten CI/CD-Abläufen frühere Bereitstellungsengpässe beseitigt haben.

Länder-Stores: Rollout in Tagen

Die Rollout-Geschwindigkeit zählt neben der Performance vor allem für Unternehmen mit internationaler oder mehrmarkenfähiger Expansion. Mit einer wiederholbaren Architektur wird aus jedem neuen Markt ein bekannter, planbarer Ablauf. Die nächste Expansion ist der richtige Anlass, mit uns über deine Plattform und die realistische Zeit bis zum nächsten Store zu sprechen.