Vor ein paar Tagen haben wir argumentiert, dass ein AI-Coding-Agent ein Storefront in einer Stunde s…
commercetools Foundry Store Launchpad vs. Plattform
commercetools Foundry Store Launchpad vs. Plattform: Was nach dem Go-Live kommt
Ein commercetools Foundry Store Launchpad bringt deinen Storefront in wenigen Wochen live, weil es ein vorkonfiguriertes Frontend-Template mit Referenz-Integrationen ins commercetools-Backend mitbringt. Für den Betrieb über drei Jahre reicht ein Template allein aber nicht: Marketing-Tempo, Weiterentwicklung und Agentic-Readiness brauchen einen eigenständigen Management-Layer oberhalb des Launchpads.
Was ist ein commercetools Foundry Store Launchpad?
Foundry ist commercetools' Antwort auf eine wiederkehrende Kundenfrage: Wie kommt ein composable Backend schnell zu einem produktionsreifen Frontend, ohne dass jedes Projekt bei null anfängt? Ein Store Launchpad ist ein vorgebautes Storefront-Template mit Standard-Komponenten, Checkout-Flow und Anbindung an die commercetools-APIs. Du klonst das Template, passt Branding und Content an und gehst live. Für den Go-Live ist das ein echter Zeitgewinn gegenüber einem Eigenbau von null.
Wichtig ist die Abgrenzung: Ein Launchpad ist ein Startpunkt, kein Betriebsmodell. Es beantwortet die Frage „Wie komme ich schnell live?", nicht die Frage „Wer pflegt, erweitert und betreibt dieses Frontend die nächsten drei Jahre?"
Das Problem, das viele erst nach dem Go-Live merken
Die ersten Wochen mit einem Foundry-Launchpad fühlen sich gut an: Der Store ist live, das Team ist erleichtert. Dann kommt Monat vier, und drei Realitäten treffen aufeinander.
Erstens will Marketing Kampagnen-Seiten und Varianten schneller ausspielen, als das Template-Setup es ohne Custom-Code erlaubt. Jede neue Landingpage bedeutet wieder ein Engineering-Ticket, weil das Template kein eigenständiges Editing-Layer für Nicht-Entwickler mitbringt.
Zweitens verändert sich der Store weiter: neue Locales, neue Brand-Varianten, neue Backend-Integrationen wie PIM, OMS oder Personalisierung. Das Launchpad-Template ist ein guter Startzustand, aber es wächst nicht von selbst mit, jede Erweiterung braucht wieder ein Frontend-Team, das die Template-Struktur versteht und pflegt. Diese Frage wird noch drängender, seit commercetools Core Commerce und den Produktkatalog als eigenständige Module verkauft: Die Backend-Bausteine werden granularer, während das Frontend synchron mitwachsen muss.
Drittens rückt Agentic Commerce näher: KI-Agenten, die Produkte durchsuchen, vergleichen und kaufen, brauchen strukturierte Daten, sauberes Schema.org und maschinenlesbare Frontends. Ein statisches Launchpad-Template bekommt diese Fähigkeiten nicht automatisch dazu.
Das ist keine Kritik an Foundry. Ein Launchpad ist genau das, wofür es gebaut ist: ein schneller, solider Startpunkt. Die Lücke entsteht danach, im laufenden Betrieb.
Wie ein FMP-Layer das Launchpad weiterträgt
Genau hier setzt eine Frontend Management Platform (FMP) an. Statt das Foundry-Template durch etwas Neues zu ersetzen, setzt sich Laioutr als Management-Layer darüber und übernimmt drei Dinge, die das Template selbst nicht mitbringt.
Betrieb. Laioutr koppelt sich per Orchestr an die commercetools-GraphQL-API und übernimmt Hosting, CI/CD und Performance-Monitoring. Dein Engineering-Team muss keine dedizierte Frontend-Infrastruktur mehr pflegen.
Marketing-Tempo. Im Studio-Editor baut Marketing Landingpages und Kampagnen-Varianten selbst, mit Live-Preview, ohne PR-Review durch Engineering. Das Foundry-Template bleibt die Basis, Studio macht daraus ein Werkzeug für den Alltag.
Agentic-Readiness. Larry AI und die Frontend Agents für SEO, GEO, Content und Vertriebssteuerung pflegen Schema.org, optimieren Meta-Daten und reagieren auf Performance-Regressionen, ohne dass jemand manuell nachziehen muss.
Ein Kunde, der nach dem Composable-Go-live weitermacht, stellt meist dieselbe Frage: Wer baut jetzt eigentlich weiter am Frontend? Die Antwort sollte nicht „ein wachsendes internes Team" lauten müssen, wenn ein Management-Layer genau diese Lücke schließt.
Was Du gewinnst
| Dimension | Nur Foundry-Template | Mit Laioutr FMP-Layer |
|---|---|---|
| Zeit | Go-Live in Wochen, danach Engineering-Sprint pro Landingpage | Go-Live in Wochen, danach Studio-Editor in Stunden |
| Geld | Wachsendes Frontend-Team für Pflege und Erweiterung (€ 300k+/Jahr) | FMP-Service, Engineering fokussiert auf Backend-Logik |
| Qualität | Agentic-Readiness und Schema.org als Sonderaufgabe | Frontend Agents pflegen SEO und GEO laufend mit |
FAQ
Was kostet das? Details zu Tarifen findest Du unter laioutr.com/pricing. Der FMP-Layer wird zusätzlich zur bestehenden commercetools-Lizenz gebucht, nicht anstelle davon.
Ersetzt Laioutr mein Foundry-Launchpad? Nein, nicht zwingend. Laioutr übernimmt das Frontend-Komponenten-Mapping aus dem bestehenden Template und baut Studio-Editing, Betrieb und Agentic-Layer darüber. Das Launchpad bleibt der Ausgangspunkt.
Wie lange dauert die Integration? Typisch zwei bis sechs Wochen für Single-Brand-Setups, abhängig davon, wie stark das bestehende Foundry-Template bereits angepasst wurde.
Müssen wir unser commercetools-Backend anfassen? Nein. Laioutr koppelt sich über Standard-GraphQL an Dein bestehendes commercetools-Setup. Backend-Verträge, Datenmodell und Merchant Center bleiben unverändert.
Nächste Schritte
Wenn Dein Foundry-Launchpad live ist und die nächste Phase ansteht: Buch ein 20-Minuten-Gespräch, in dem wir Deine aktuelle Frontend-Architektur gegen den FMP-Layer spiegeln, ohne dass Du Dein commercetools-Backend anfasst.
Über den Autor: Marcel Thiesies ist Co-Founder von Laioutr. Er begleitet commercetools-Kunden dabei, den Frontend-Layer nach dem Go-Live zu skalieren, ohne das Backend zu wechseln.