commercetools Frontend Pricing und TCO: Was das Frontend im Composable-Paket wirklich kostet

Die meisten commercetools-Pricing-Gespräche hören bei der API auf. Teams kalkulieren die Commerce-Backend-Lizenz, das Request-Volumen, das Integrationsbudget, und behandeln den Storefront danach als Posten, den Engineering schon irgendwie stemmt. Das Ergebnis ist eine Total-Cost-of-Ownership-Zahl (TCO), die auf der Folie vollständig aussieht, aber genau die Schicht auslässt, die Kund:innen tatsächlich anfassen. commercetools ist ein Headless-Commerce-Backend, das heißt: das Frontend ist nicht enthalten. Irgendjemand muss es bauen, hosten, warten und betreiben, und diese Arbeit läuft über die gesamte Lebensdauer des Storefronts, nicht nur im Launch-Quartal. Das hier ist eine sachliche Aufschlüsselung, woher die Frontend-Kosten im commercetools-Stack kommen, ohne erfundene Zahlen, damit du die Treiber für deinen eigenen Fall einordnen kannst.

Was commercetools beim Frontend enthält, und was nicht

commercetools liefert APIs, keinen Storefront. Du bekommst das Composable-Commerce-Backend (Produkt-, Warenkorb-, Bestell- und Kundendaten über GraphQL und REST), das Merchant Center für die Backend-Administration und, je nach Paket, Werkzeuge wie Frontend (das frühere Frontastic) als optionale Schicht. Was du out of the box nicht bekommst, ist ein laufender, gebrandeter, SEO-fähiger Storefront mit einem Seiten-Editor, den dein Marketing-Team ohne Entwickler:in bedienen kann.

Diese Lücke ist Absicht. Composable Commerce entkoppelt das Backend bewusst von der Präsentationsschicht, damit du deinen eigenen Frontend-Ansatz wählen kannst. Der Preis dafür: die Präsentationsschicht wird zu deiner Verantwortung. Egal ob du commercetools Frontend, ein separates Frontend-Framework oder eine Frontend Management Platform einsetzt, der Storefront ist ein eigenes Kostenzentrum mit eigenem Build-, Hosting- und Wartungsprofil. Die commercetools-Backend-Preise als Gesamtkosten des Go-live zu lesen, ist der häufigste Budgetierungsfehler in einem Composable-Projekt.

Build vs. Buy für den Storefront

Sobald das Backend steht, ist die erste echte Entscheidung Build vs. Buy für das Frontend selbst. Beides ist valide, und beides kostet, nur in unterschiedlicher Form.

Der Build-Pfad

Ein Custom-Storefront, typischerweise auf einem Framework wie Next.js, Nuxt oder Remix, gibt dir volle Kontrolle. Dein Team ownt die Komponenten, die Rendering-Strategie und die Integrations-Verdrahtung zu commercetools und zu jedem Best-of-Breed-Service (Suche, Payments, Subscriptions). Die Kosten sind hier vorgezogen und laufend: ein dediziertes Frontend-Team bis zum Launch, danach eine stehende Kapazität, um alles aktuell zu halten, während Backend, Browser und Framework sich weiterbewegen.

Der Buy-Pfad

Buy heißt, ein Frontend-Produkt zu übernehmen, entweder commercetools Frontend oder eine Plattform für ein Composable, Headless Frontend, die die Storefront-Hülle, eine Editing-Oberfläche und vorgebaute Integrations-Muster mitbringt. Du tauschst ein Stück Low-Level-Kontrolle gegen einen kürzeren Weg zum Launch und ein kleineres stehendes Engineering-Commitment. Die Kosten verschieben sich von Gehältern hin zu einer Plattform-Gebühr plus Konfigurationsaufwand.

Die ehrliche Einordnung ist nicht "Build teuer, Buy billig". Sie lautet: Build übersetzt Kosten in Headcount und Kalenderzeit, Buy übersetzt Kosten in eine planbare Gebühr und schnellere Iteration. Was über drei Jahre günstiger ist, hängt fast vollständig an den Hidden Costs unten.

Die versteckten Kosten eines selbstgebauten Frontends

Wenn Teams die Frontend-TCO unterschätzen, liegt es meist daran, dass diese vier Treiber im Modell fehlen. Keiner davon taucht in einer Backend-Lizenz auf.

Hosting und Delivery

Ein Storefront braucht Rendering-Infrastruktur, ein CDN, Edge- oder Server-Side-Rendering für SEO und Performance, Bildoptimierung und Caching. Das sind wiederkehrende Kosten, die mit dem Traffic und mit der Zahl der Märkte und Locales skalieren, die du bedienst. Peak-Events (Sales, Kampagnen) bestimmen das Sizing, du zahlst also für Reserve, die du ein paar Mal im Jahr nutzt.

Wartung und Upgrades

Ein Frontend ist nie fertig. Framework-Major-Versionen, Security-Patches für Dependencies, Browser-Änderungen, Accessibility-Anforderungen und commercetools-API-Updates verlangen laufend Engineering-Aufmerksamkeit. Diese Wartungslast wird leicht aus dem Launch-Budget weggelassen und ist oft der größte Mehrjahres-Kostenblock, weil sie nie aufhört und direkt mit neuer Feature-Arbeit konkurriert.

Editor- und Authoring-Tooling

Wenn Marketing eine Landingpage, einen Hero oder einen Kampagnen-Block nicht ohne Entwickler:in ändern kann, wird jede Content-Änderung zum Ticket. Die Kosten zeigen sich dann doppelt: als Entwicklerzeit für Content-Arbeit und als langsamere Time-to-Market für Kampagnen. Eine fähige Schicht für Visual Editing und Content Management ist im TCO-Sinn kein Nice-to-have, sie hält Routine-Änderungen aus dem Engineering-Backlog heraus.

Entwicklerzeit und Opportunitätskosten

Der am stärksten unterschätzte Treiber ist, wofür Senior-Frontend-Engineers ihre Woche verwenden. Zeit, die in einen umgebauten Header, das Anbinden eines neuen Payment-Providers im Checkout oder das Debuggen einer Rendering-Regression fließt, ist Zeit, die nicht in differenzierende Experience-Arbeit fließt. In einem Composable-Stack ist das Versprechen Best-of-Breed überall, aber jeder Best-of-Breed-Service muss trotzdem integriert und gerendert werden, und diese Integrationsfläche liegt im Frontend.

Wie eine Frontend Management Platform die TCO-Rechnung verändert

Eine Frontend Management Platform (FMP) sitzt zwischen dem commercetools-Backend und dem Storefront und übernimmt genau die Treiber von oben. Sie ersetzt commercetools nicht, sie rendert es. Der Punkt ist nicht, dass eine FMP kostenlos wäre, sie hat ihre eigene Gebühr, sondern dass sie mehrere separate Kostenzeilen zu einer bündelt und die stehende Wartungslast von deinem Team nimmt.

Konkret verändert eine FMP die Rechnung an vier Stellen. Hosting, Rendering und Delivery werden Teil der Plattform statt Infrastruktur, die du selbst dimensionierst und betreibst. Framework- und Dependency-Upgrades passieren auf Plattform-Ebene, dein Team verbringt also keine Sprints mit Wartung, die keinen neuen Kundennutzen erzeugt. Editing wandert auf eine visuelle Oberfläche, Content- und Kampagnen-Änderungen verlassen den Engineering-Backlog. Und die Integration zu Best-of-Breed-Services läuft über eine einheitliche Datenschicht, das Anbinden von Suche, Payments oder Subscriptions ist Konfiguration statt jedes Mal ein maßgeschneiderter Build. Das ist das Modell hinter Frontend as a Service: die Frontend-Schicht wird zu einem betriebenen Service mit planbaren Kosten, statt zu einem Projekt, das dein Team unbegrenzt finanziert und wartet.

Das Ergebnis ist nicht automatisch im ersten Jahr günstiger. Ein gut besetztes Team, das einen fokussierten Storefront baut, kann so oder so wettbewerbsfähig launchen. Der Unterschied summiert sich über Jahr zwei und drei, wo der Selbstbau-Pfad weiter für Wartung, Hosting-Reserve und Entwicklerzeit für Content zahlt, während der FMP-Pfad diese als flache Gebühr hält und dieselben Engineers für Revenue-Arbeit freispielt.

Selbstgebautes Frontend vs. FMP-betriebenes Frontend: die TCO-Treiber

• TCO-Treiber | Selbstgebautes Frontend | FMP-betriebenes Frontend
• Initialer Build | Dediziertes Frontend-Team bis Launch | Konfiguration auf bestehender Hülle
• Hosting und Delivery | Intern dimensioniert, bezahlt, betrieben | Teil der Plattform-Gebühr
• Framework- und Security-Upgrades | Laufende Team-Verantwortung | Auf Plattform-Ebene erledigt
• Editor-Tooling | Separat gebaut oder lizenziert | Enthaltene Visual-Editing-Oberfläche
• Best-of-Breed-Integration | Maßgeschneiderter Build pro Service | Konfiguration über einheitliche Datenschicht
• Kostenform | Headcount plus Infrastruktur | Planbare wiederkehrende Gebühr
• Tempo bei Content-Änderungen | Entwickler-Ticket | Marketing im Self-Service

FAQ

Ist im commercetools-Lizenzpreis ein Storefront enthalten? Nein. commercetools ist ein Headless-Commerce-Backend. Es liefert APIs, das Merchant Center und optionales Frontend-Tooling, aber ein laufender, gebrandeter Storefront ist eine eigene Build-oder-Buy-Entscheidung mit eigenem Kostenprofil.

Was ist die größte versteckte Frontend-Kostenstelle bei commercetools? Meist die laufende Wartung: Framework-Upgrades, Security-Patches und API-Änderungen, die nie aufhören und mit neuer Feature-Arbeit konkurrieren. Dicht dahinter: Hosting-Reserve für Peak-Traffic und Entwicklerzeit für Content-Änderungen.

Ist ein Custom-Frontend immer teurer als Buy? Nicht im ersten Jahr. Ein fokussiertes Team kann wettbewerbsfähig launchen. Die Lücke öffnet sich über mehrere Jahre, wo der Selbstbau-Pfad weiter für Wartung, Hosting und Entwicklerzeit für Routine-Änderungen zahlt.

Wie senkt eine Frontend Management Platform die TCO? Sie bündelt Hosting, Rendering, Upgrades, Editor-Tooling und Integration in einer betriebenen Schicht mit planbarer Gebühr und nimmt deinem Team die stehende Wartungslast, damit Engineers ihre Zeit stattdessen in differenzierende Arbeit stecken.

Müssen wir commercetools verlassen, um eine FMP zu nutzen? Nein. Eine FMP rendert das commercetools-Backend über dessen APIs. Das Backend bleibt deine Source of Commerce Truth, die FMP ownt die Präsentations- und Delivery-Schicht darüber.

Weitere Themen aus der Laioutr-Plattform

• Composable Headless Frontend: wie sich die Frontend-Schicht ohne Custom-Build an ein commercetools-Backend anbindet.
• Frontend as a Service: das Betriebsmodell, das Bauen-und-Warten in eine planbare Gebühr verwandelt.
• Agentic Frontend Management Platform: wie KI-Agenten Routine-Frontend-Änderungen übernehmen, die sonst Entwicklerzeit kosten.
• Composable Digital Experience Platform: wo Visual Editing und Content Management im Composable-Stack sitzen.

Nächster Schritt

Willst du die Frontend-Schicht deiner commercetools-TCO mit echten Treibern beziffern statt mit einem Platzhalter-Posten? Sprich mit dem Laioutr-Team und wir gehen durch, wo deine Storefront-Kosten wirklich liegen und was ein betriebenes Frontend verändern würde.