In 19 Tagen steht commercetools auf der K5 Berlin mit Booth #37 - vom 23. bis 24. Juni. Das Partner-Lineup ist dicht: basecom, MGM Technology Partners und neteleven sind vor Ort. Am Abend gibt es eine Pizza-Rooftop-Session mit fulfilmenttools und KPS. Gut geplante Teilnahme - und eine Gelegenheit, die man als CTO oder Architecture Lead konkret nutzen kann.

Konkret heißt: nicht mit abstrakten Roadmap-Fragen zum Stand gehen, sondern mit drei Fragen, die operativ entscheiden, ob deine Frontend-Strategie in 36 Monaten noch funktioniert. Dieser Post liefert genau das. Keine commercetools-Kritik, keine Hype-Prophezeiungen - sondern die Fragen, die du dir ohnehin stellen wirst, wenn du das Projekt ein Jahr nach Launch neu bewertest.

Frage 1: Was kostet commercetools Frontend vs. Eigenbau vs. FMP nach 36 Monaten wirklich?

Die häufigste Entscheidungssituation bei commercetools-Projekten: Du hast das Backend evaluiert und freigegeben. Jetzt steht die Frontend-Wahl. Drei Optionen liegen auf dem Tisch.

Option A: commercetools Frontend (vormals Frontastic). Der Vorteil ist die direkte commercetools-Integration und Support-Nähe zum Vendor. Die offene Frage: Wie verhält sich der TCO, wenn du in 24 Monaten eine zweite Brand launchst, eine neue Locale aufmachst oder ein anderes Marketing-Tool anbindest? commercetools Frontend ist tief in das commercetools-Ökosystem integriert - das ist Stärke und Abhängigkeitsfaktor zugleich. Was kostet ein Frontend-Modul-Wechsel in diesem Setup?

Option B: Eigenbau-Frontend mit Next.js oder Nuxt. Maximale Kontrolle, aber realistischer TCO nach 36 Monaten umfasst: initiale Implementierung typisch 200.000 bis 1 Million Euro, laufendes Frontend-Team inklusive On-Call und Maintenance typisch ab 300.000 Euro jährlich, dazu Connector-Maintenance pro commercetools-API-Update. Wer das Team intern hat, rechnet anders als wer es extern finanziert.

Option C: Frontend Management Platform (FMP) als externer Layer. Ein FMP wie Laioutr setzt als Frontend-Layer auf die commercetools GraphQL-API und entkoppelt das Frontend vom Backend-Vendor. Kein Frontastic-Lock-in, kein dauerhaftes Eigenbau-Frontend-Team. Die Gegenfrage für den Booth: Wie unterscheidet commercetools selbst zwischen dem, was ein FMP leistet, und dem, was commercetools Frontend bietet?

Die konkrete Frage für Booth #37 lautet: Was ist der vertraglich fixierbare Preispfad für commercetools Frontend über 36 Monate bei Skalierung auf zwei Brands, zwei Locales und 10 neuen Integrationen?

Die Antwort zeigt dir, ob Option A ein planbarer Budgetposten bleibt oder ob der TCO ab einer bestimmten Skalierungsstufe eskaliert. Einen strukturierten Vergleich der drei Optionen findest du in unserem Vergleichs-Post zu commercetools Frontend-Alternativen.

Frage 2: Wie agent-aware ist das aktuelle Storefront-Pattern?

Das ist die Frage, die 2026 noch selten am Stand gestellt wird - und genau deshalb die relevanteste für ein K5-Gespräch mit Tiefe.

Agentic Commerce ist kein Markt-Trend mehr, der in 18 Monaten relevant wird. AI-Käufer erzeugen heute messbaren Traffic auf Storefronts. Wenn ein autonomer Agent eine Produktrecherche oder einen Kaufprozess durchläuft, stellt er strukturell andere Anforderungen als ein menschlicher Shopper: stabile API-Verträge, maschinenlesbare Datenstrukturen, Schema.org-Markups mit vollständiger Product- und Offer-Coverage, deterministisch konsumierbare GraphQL-Endpunkte.

Die Frage an den Stand ist zweigeteilt:

Erstens: Wie stabil sind die commercetools-GraphQL-Verträge über API-Versionen hinweg? Ein Agent, der Produkt- und Preisdaten konsumiert, braucht einen Endpunkt, der sich nicht mit jedem Release strukturell ändert. Was ist commercetools' aktuelle Versionierungs-Policy für die Storefront-API?

Zweitens: Was liefert commercetools Frontend als maschinenlesbaren Output? Ist das Storefront-Rendering auf strukturierte Daten optimiert - JSON-LD, Schema.org-Felder in vollständiger Coverage - oder ist das eine Customer-Aufgabe in der Frontend-Implementierung?

Wenn du ein Composable-Backend wie commercetools mit einem agent-ready Frontend kombinierst, entsteht ein Architekturmuster, das für die nächste Shopper-Generation gebaut ist. Wenn das Storefront-Rendering den agent-aware Layer nicht mitliefert, ist das ein Eigenbauprojekt. Die Frage am Stand: Wer ist bei commercetools verantwortlich für die agent-ready Storefront-Schicht - der Vendor, der Partner oder der Customer?

Das Thema ist Pillar-4-Kern bei uns - mehr zum Composable-Commerce-Stand 2026 und agent-aware Architekturen findest du im State of Composable Commerce 2026.

Frage 3: Was passiert mit dem Frontend, wenn ein Backend-Modul getauscht wird?

Das ist der Test der Composable-Promise. commercetools wirbt damit, dass einzelne Backend-Fähigkeiten austauschbar sind: OMS, PIM, Pricing-Engine, Promotion-Logik. Die Theorie ist richtig. Die Frage ist: Gilt das auch für das Frontend?

Ein konkretes Szenario: Du hast commercetools im Backend und möchtest die Promotion-Engine durch einen Drittanbieter ersetzen - zum Beispiel weil die native commercetools Discount-Logik bei komplexen B2B-Rabatten an ihre Grenzen stößt. Was passiert in diesem Moment mit dem Frontend?

Bei einem Eigenbau-Frontend mit direkter API-Anbindung: Das Frontend-Team muss die neue Promotion-Engine anbinden, bestehende Komponenten anpassen, testen und deployen. Zeitaufwand je nach Integrationstiefe.

Bei commercetools Frontend: Wie verhält sich das Frontend-Tooling, wenn eine Backend-Komponente durch einen Nicht-commercetools-Anbieter ersetzt wird? Ist das Frontend auf genau diesen Backend-Mix kalibriert oder abstrahiert es die Modul-Grenzen?

Bei einem FMP mit Unified Data Layer: Der Orchestration-Layer normalisiert Produkt-, Bestands- und Preis-Daten aus mehreren Quellen in ein einheitliches Frontend-Schema. Ein Backend-Modul-Swap bedeutet theoretisch: neue Connector-Konfiguration im Data Layer, kein Frontend-Rewrite. Das ist die Decoupling-Versprechen-Einlösung, die Composable Commerce verspricht.

Die Frage für Booth #37: Gibt es einen dokumentierten Fall, in dem ein commercetools-Customer ein Backend-Modul ausgetauscht hat, ohne das Frontend neu zu schreiben - und was war der konkrete Aufwand im Frontend-Layer?

Die Antwort zeigt dir, ob Composable Architecture bei commercetools auch auf der Frontend-Seite gelebt wird oder ob die Composable-Promise im Backend endet.

Was du mit diesen drei Fragen am Stand erreichst

Du bekommst keine Verkaufspräsentation zurück. Du bekommst Informationen, die du für eine fundierte Architekturentscheidung brauchst.

TCO nach 36 Monaten ist nicht abstrakt - er hat drei Treiber: initiale Implementierung, laufende Maintenance und Skalierungskosten. Alle drei variieren je nach Frontend-Modell stark.

Agent-aware Architekturen sind heute kein Nice-to-Have mehr. Wer ein Storefront-Redesign in den nächsten 12 Monaten plant und den agent-ready Layer nicht einbaut, baut zweimal.

Backend-Modul-Swap-Stabilität ist der Realitätscheck der Composable-Promise. Wenn das Frontend bei jedem Backend-Wechsel mitgebaut werden muss, ist Composable Commerce im Backend eine halbe Antwort.

Alle drei Fragen hängen zusammen: Sie beschreiben den Frontend-Layer als eigenständige Architekturentscheidung, die unabhängig vom Backend-Vendor getroffen und bewertet werden sollte.

Wenn du nach der K5 eine strukturierte Frontend-Evaluation für dein commercetools-Setup willst - wie die drei Optionen (Frontastic, Eigenbau, FMP) gegen deine konkreten Skalierungsszenarien abschneiden - findest du den Einstieg auf unserer Headless Frontend for commercetools Seite. Dort ist auch dokumentiert, wie Laioutr als Frontend Management Platform auf commercetools GraphQL aufsetzt und was das konkret bedeutet für TCO, Time-to-Market und Backend-Unabhängigkeit.

basecom, MGM und neteleven kennen die Implementierungs-Realität aus ihrer Projektarbeit. Die Fragen oben funktionieren genauso gut im Gespräch mit den Partnern wie am commercetools-Stand selbst.

K5, 23. bis 24. Juni, Booth #37. 19 Tage.