Integrationen per Klick: App Store statt Engineering-TicketTime-to-Market entscheidet sich selten im…
Integrationen per Klick: App Store statt Engineering-Ticket
Integrationen per Klick: App Store statt Engineering-Ticket
Time-to-Market entscheidet sich selten im Architektur-Diagramm. Sie entscheidet sich an einer viel banaleren Frage: Wer darf ein Tool anschließen? Solange jede Such-, Analytics- oder Personalisierungs-Anbindung als Engineering-Ticket startet, bleibt die Modularität Deines Backends für das Marketing-Team folgenlos.
Der Markt modularisiert das Backend. Und dann?
Seit Juli 2026 verkauft commercetools seine Plattform in einzeln buchbaren Modulen. Core Commerce und Product Catalog lassen sich getrennt einführen, statt als vollständiges Replatforming. Doug McNary, CEO von commercetools, begründet das im Press Release zu Modular Commerce so: "As the pace of commerce innovation accelerates, companies can no longer afford to wait years to modernize. Enterprises want to solve immediate business problems, prove value quickly and evolve over time."
Der Markt-Move ist eindeutig, und er ist richtig. Wenn selbst der Composable-Platzhirsch sein Angebot in Module zerlegt, ist die Botschaft klar: Modernisierung läuft inkrementell, nicht als Big Bang.
Nur verschiebt das die eigentliche Frage, statt sie zu beantworten. Ein Backend-Modul liefert Daten. Geschäftswert entsteht erst, wenn diese Daten im Storefront ankommen und dort mit den Tools zusammenspielen, mit denen Marketing tatsächlich arbeitet. Genau an dieser Nahtstelle liegt der Engpass, den kaum jemand im Architektur-Review adressiert.
Integration ist keine technische Frage, sondern eine Berechtigungsfrage
Schau Dir an, was ein durchschnittliches Marketing-Team im Laufe eines Quartals wirklich braucht: Algolia für die Produktsuche, Klaviyo für Lifecycle-Mails, Google Analytics 4 und Hotjar für Verhaltensdaten, Contentful für redaktionelle Inhalte, Unzer für Payment, Akeneo für Produktdaten. Keine dieser Anbindungen ist technisch ungelöst. Alle sind dokumentiert, alle haben stabile APIs, alle sind hundertfach implementiert worden.
Trotzdem dauert jede einzelne Wochen. Nicht weil sie schwierig ist, sondern weil sie durch eine Warteschlange muss: Ticket schreiben, Priorisierung im Sprint-Planning, Implementierung, Code-Review, QA, Deployment-Fenster. Der Aufwand pro Anbindung ist überschaubar. Die Wartezeit davor ist es nicht.
Das Ergebnis kennst Du wahrscheinlich: Kampagnen werden nach dem geplant, was bereits angeschlossen ist, nicht nach dem, was funktionieren würde. Ein A/B-Test auf einem neuen Personalisierungs-Anbieter wird nicht verworfen, weil er schlecht wäre, sondern weil niemand vier Wochen Vorlauf für ein Experiment budgetiert. Genau das ist gemeint, wenn wir sagen, dass Frontend Management der eigentliche Time-to-Market-Hebel im E-Commerce ist: Die Geschwindigkeit einer Organisation misst sich an ihrem langsamsten Freigabepfad, nicht an ihrer schnellsten API.
Was Click-to-Connect konkret ändert
Der Laioutr App Store dreht diesen Pfad um. Statt pro Tool ein Integrations-Projekt aufzusetzen, wählst Du die App im Cockpit aus, hinterlegst die Zugangsdaten und konfigurierst, wo sie im Storefront greift. Aktuell listet der Katalog mehr als 300 Integrationen (Stand 29. August 2026), von Search und Analytics über Content und PIM bis Payment. Wir haben den Katalog im Januar 2026 als ersten App Store für Composable Frontends gestartet und ihn seitdem kontinuierlich erweitert.
Wichtig dabei: Das ist kein Freifahrtschein. Engineering definiert weiterhin die Guardrails, welche Apps zugelassen sind, welche Datenfelder sie sehen und in welchen Umgebungen sie laufen. Marketing komponiert innerhalb dieser Grenzen. Laioutr ist Low-Code für Marketing-Teams und gleichzeitig code-fähig für Entwicklung, nicht ein Werkzeug, das Governance ersetzt.
- Auslöser - Klassischer Weg: Jira-Ticket an Engineering. Mit App Store: Auswahl im Cockpit.
- Wartezeit - Klassischer Weg: Sprint-Zyklus plus Deployment-Fenster. Mit App Store: keine Warteschlange.
- Wer entscheidet - Klassischer Weg: Backlog-Priorisierung. Mit App Store: Marketing, innerhalb der Guardrails.
- Rollback - Klassischer Weg: erneutes Deployment. Mit App Store: Konfiguration deaktivieren.
- Aufwand pro Tool - Klassischer Weg: einmalig Custom-Glue, dauerhaft Wartung. Mit App Store: Konfiguration, zentral gepflegt.
Der zweite Effekt ist der interessantere: Wenn Anschließen billig wird, wird Ausprobieren billig. Ein Search-Provider, der im Test nicht überzeugt, kostet Dich eine Konfiguration statt eines Quartals. Das verändert, welche Experimente ein Team überhaupt in Betracht zieht.
Was Du dadurch gewinnst
Der Effekt bleibt nicht bei den Integrationen stehen. Er wirkt auf die gesamte Ausspielseite. Laut den auf laioutr.com ausgewiesenen Kennzahlen liegt die Time-to-Launch für neue Landingpages um 65 Prozent unter der eines klassischen Headless-Setups, und eine Migration mit Founder-Begleitung dauerte im Median unter 14 Tagen (Q1 und Q2 2026).
Beide Zahlen haben dieselbe Ursache. Nicht schnellere Entwickler, sondern weniger Übergaben. Wer Seiten im Visual Page Builder selbst baut, die Inhalte über Content Management selbst pflegt und die Tools dahinter selbst anschließt, braucht pro Kampagne genau null Sprint-Slots.
Für Teams, die ihr Backend gerade modularisieren, schließt sich damit der Kreis. Wenn Du commercetools als Backend fährst, dockt das Headless Frontend für commercetools über die Standard-GraphQL-Anbindung an, und die Apps liegen im selben Layer darüber. Das Backend bleibt modular, und die Ausspielseite hält mit.
Was das für Dein Team bedeutet
Wenn Du Marketing oder E-Commerce verantwortest, lohnt sich eine unangenehme Inventur: Wie viele Deiner letzten zehn Kampagnen-Ideen sind an der Anbindung gescheitert, nicht an der Idee? Wie viele Tools laufen bei Euch parallel, weil das eine gute nicht angeschlossen werden konnte?
Die Antwort darauf ist keine neue Tool-Entscheidung. Sie ist eine Architektur-Entscheidung auf der Frontend-Seite: Liegt die Integrationsfähigkeit im Code Deiner Storefront oder in einer Konfigurationsebene darüber? Im ersten Fall bleibt jede Anbindung ein Release. Im zweiten wird sie eine Einstellung.
FAQ
Heißt das, wir brauchen kein Engineering mehr? Nein. Engineering definiert die Guardrails, prüft neue Apps und baut alles, was über den Katalog hinausgeht. Was entfällt, ist der Sprint pro Standard-Anbindung.
Was passiert mit Tools, die nicht im Katalog stehen? Die bindest Du weiterhin individuell an, über die Standard-Schnittstellen der Plattform. Der Katalog deckt den Standardfall ab, nicht jeden Sonderfall.
Müssen wir dafür unser Backend wechseln? Nein. Der App Store liegt im Frontend-Layer und ist backend-agnostisch. Dein Commerce-Backend bleibt, wo es ist.
Wie behalten wir die Kontrolle über Datenschutz und Consent? Apps werden zentral freigegeben und konfiguriert, inklusive Consent-Kopplung für Tracking-Tools. Die Freigabe bleibt bei den Verantwortlichen, nicht bei der Person, die die App auswählt.
Nächste Schritte
Sieh Dir an, welche Deiner aktuellen Tools bereits im Laioutr App-Katalog liegen. Wenn drei oder mehr davon bei Euch heute Engineering-Tickets brauchen, hast Du Dein Rechenbeispiel für das nächste Quartal.