TCO eines Composable Frontends: Die 5-Jahres-Sicht, die in Business-Cases fehlt

Replatforming-Business-Cases sehen meistens gleich aus: Implementierungskosten des neuen Systems auf der einen Seite, eingesparte Lizenzkosten des alten auf der anderen. Fertig ist die Rechtfertigung.

Das Problem: Diese Rechnung unterschlägt die Hälfte der tatsächlichen Kosten. Und genau diese zweite Hälfte entscheidet, ob ein Composable-Commerce-Projekt nach drei Jahren als Erfolg oder als Kostenfalle bewertet wird.

Dieser Post legt die Kostendimensionen offen, die in den meisten Business-Cases fehlen, und gibt einen Rahmen für eine realistische 5-Jahres-TCO-Berechnung des Composable Frontends.

Warum der Standard-Business-Case zu kurz greift

Der klassische Replatforming-Business-Case denkt in Implementierungsphasen: Discovery, Design, Build, Launch. Nach dem Launch gilt das Projekt als "fertig" - und die Folgekosten wandern in ein diffuses Betriebsbudget, das selten demselben Scrutiny unterliegt wie die Entscheidungsvorlage.

Im Composable-Kontext ist das besonders kritisch, weil Composable-Architekturen per Definition aus mehreren Systemen bestehen, die koordiniert werden müssen. Jeder Schnittpunkt - Backend, Middleware, Frontend - hat eigene Evolutionskosten, eigene Team-Expertise-Anforderungen, eigene Update-Zyklen.

Die 5-Jahres-Sicht ist nicht akademisch. Sie ist die minimale Zeitachse, auf der sich eine substantielle Replatforming-Investition amortisieren muss.

Kostenposten 1: Initiale Implementierung (Jahr 0-1)

Das ist der Bereich, den Business-Cases am besten abdecken. Typische Positionen:

• Agency-/Partner-Kosten für Discovery, Design, Entwicklung
• Lizenz-Setup für alle Systemkomponenten (Commerce-Backend, Headless-CMS, PIM, Frontend-Platform)
• Datenmigration und Integration-Testing
• Launch-Phase (Parallelbetrieb alter und neuer Stack)

Häufig unterschätzt: Die Integration-Testing-Phase. In Composable-Stacks mit 5-8 Systemen ist das E2E-Testing komplex - besonders wenn Search, Personalisierung und Checkout eigene Systeme sind. Realistische Zeitplanung: 30-40 % länger als in Monolith-Projekten.

Typische Range: 150.000 - 800.000 Euro je nach Stack-Komplexität und Team-Mix (Inhouse vs. Agentur). Für große Enterprise-Stacks oberhalb dieser Range.

Kostenposten 2: Laufende Lizenzkosten (Jahr 1-5)

Composable-Stacks addieren Lizenzen, die in Monolith-Rechnungen oft nicht vorkommen:

| Systemkomponente | Typische jährliche Lizenzkosten | |---|---| | Commerce-Backend (SaaS, z.B. commercetools, Shopware Cloud) | 15.000 - 120.000 EUR/Jahr | | Headless-CMS (z.B. Contentful, Storyblok) | 10.000 - 60.000 EUR/Jahr | | PIM (z.B. Akeneo, Pimcore) | 12.000 - 80.000 EUR/Jahr | | Frontend-Platform (FMP) | 15.000 - 80.000 EUR/Jahr | | Search (z.B. Algolia, Klevu) | 8.000 - 50.000 EUR/Jahr | | Personalisierung / CDP | 20.000 - 100.000 EUR/Jahr |

Hinweis: Lizenzmodelle ändern sich. Was 2026 gilt, gilt nicht unbedingt 2028. Mehrere SaaS-Anbieter haben 2024-2025 ihre Preismodelle verschärft - das erhöht das Risiko für Business-Cases, die auf aktuellen Listenpreisen basieren.

Empfehlung: Lizenzkosten mit 10-20 % jährlicher Eskalation einkalkulieren, insbesondere bei Usage-basierten Modellen (API-Calls, Traffic-Bandbreite).

Kostenposten 3: Engineering-Aufwand für Wartung und Evolution (Jahr 1-5)

Das ist die größte Unterschätzungsquelle in Composable-Business-Cases.

Dependency-Updates. Ein Composable-Frontend-Stack hängt von zahlreichen Paketen ab: Framework-Version, Connector-Libraries, Design-System-Pakete, CI/CD-Tools. In einem Next.js oder Nuxt-basierten Stack mit 15-20 direkten Dependencies sind Major-Version-Updates regelmäßige Aufgaben. Reale Kalkulation: 2-4 Engineer-Wochen pro Jahr nur für Dependency-Hygiene.

API-Breakage-Handling. Wenn Vendor-A eine neue API-Version einführt und die alte deprecated, muss das Frontend angepasst werden. Bei 3-5 angebundenen Backends ist das kein Einzel-Event, sondern ein kontinuierliches Engineering-Thema. Kalkulation: 4-8 Engineer-Wochen pro Jahr.

Performance-Monitoring und Regression-Behandlung. Core Web Vitals degenerieren aktiv bei fehlender Pflege: neue Third-Party-Scripts, größere Bundle-Größen, veraltete Image-Optimierung. Wer LCP unter 2,5s halten will, muss aktiv gegensteuern. Kalkulation: 2-4 Engineer-Wochen pro Jahr.

Team-Onboarding und Wissenstransfer. Composable-Stacks haben höhere Expertise-Anforderungen als Monolithen. Jeder neue Developer muss mehrere Systeme und ihre Schnittstellenverträge verstehen. Mit einer durchschnittlichen Fluktuation von 20 % im Engineering ist das ein kalkulierbarer Dauerposten.

Gesamt-Engineering-Overhead (Maintenance): 15-25 % des Jahres-Engineering-Budgets, je nach Stack-Komplexität. Bei einem 3-Personen-Frontend-Team bedeutet das 0,5 bis 0,75 FTE, die dauerhaft für Maintenance gebunden sind.

Kostenposten 4: Content- und Marketing-Team-Aufwand (Jahr 1-5)

Business-Cases fokussieren auf Engineering-Kosten. Marketing-Team-Aufwand für das Frontend bleibt oft ausgeblendet.

Training und Toolwechsel. Ein neues CMS oder ein neues Studio-Interface braucht Onboarding. Selbst wenn das Interface intuitiv ist: erste 2-3 Monate nach Launch sind Marketing-Teams langsamer als vorher. Kalkulation: 10-20 % Produktivitätsverlust für 2-3 Monate post-Launch.

Abhängigkeit von Engineering für Nicht-Standard-Aufgaben. Wenn Marketing neue Komponenten braucht, die nicht im Design-System existieren, wird Engineering involviert. Wie viele solcher Tickets entstehen pro Quartal? In der Praxis: 5-15 Tickets/Quartal für nicht-konfigurierbare Anforderungen. Kalkulation: 0,2-0,5 Engineer-Wochen pro Quartal.

Empfehlung: Einen Visual Page Builder mit breitem Konfigurations-Spielraum wählen, der Marketing-Teams echte Autonomie gibt - nicht eine Lösung, die für jede neue Landingpage einen Engineering-Ticket braucht.

Kostenposten 5: Performance- und Qualitätssicherung (Jahr 1-5)

Accessibility-Compliance. Das BFSG (Barrierefreiheitsstärkungsgesetz) gilt seit dem 28. Juni 2025 für digitale Produkte in Deutschland. Wer kein a11y-konformes Frontend hat, muss nachrüsten - und das ist teuer. Kalkulation für einen nachträglichen A11y-Sprint: 4-8 Wochen Engineering-Zeit.

Security-Patching und Zertifizierungen. Headless-Frontends exponieren mehr Oberfläche als Monolithen: CDN-Konfiguration, API-Authentication, Server-Side-Rendering-Layer. Bei managed Plattformen entfällt dieser Aufwand weitgehend. Bei self-hosted Setups: 2-4 Wochen/Jahr.

Lighthouse-Pflege. Core Web Vitals als Google-Ranking-Faktor erfordern kontinuierliche Aufmerksamkeit. Performance-Budgets aufsetzen, Regressions-Alarmierung einrichten, bei Abweichungen reagieren. Das ist keine einmalige Aufgabe.

Die versteckten Kosten: Was selten in Business-Cases erscheint

Neben den expliziten Kostenpositionen gibt es Kosten, die schwerer zu benennen sind, aber real sind:

Opportunity Cost durch Deployment-Verzögerung. Wenn Marketing für jeden neuen Hero-Banner auf ein Engineering-Ticket wartet, sind das verlorene Conversion-Opportunities. Quantifizierbar: wenn 10 Banner-Änderungen pro Quartal je 3 Tage warten, ist das potenziell 120 verlorene Tage Marketing-Agilität pro Jahr.

Vendor-Eskalationsrisiko. Was passiert, wenn ein Vendor im Stack seine Preise verdoppelt oder sein Produkt einstellt? Composable-Stacks haben mehr Vendor-Abhängigkeiten als Monolithen - jede davon ist ein latentes Risiko. Nicht als Kostenpunkt quantifizierbar, aber als Risikopuffer einkalkulierbar.

Architektur-Drift. Ohne aktive Governance entfernen sich Composable-Stacks über Zeit von ihrer ursprünglichen Architekturvision. Custom-Glue-Code häuft sich an, temporäre Workarounds werden permanent, Dokumentation veraltet. Nach 3-4 Jahren ist Refactoring ein signifikantes Engineering-Projekt.

Ein realistisches 5-Jahres-TCO-Modell

Für einen mittelständischen Commerce-Stack (50-500 Mio. EUR GMV, 3 Frontend-Engineer-FTE):

| Kostenposition | Jahr 1 | Jahr 2-5 (Summe) | Gesamt 5 Jahre | |---|---|---|---| | Initiale Implementierung | 250.000 EUR | - | 250.000 EUR | | Lizenzen (alle Komponenten) | 60.000 EUR | 280.000 EUR | 340.000 EUR | | Engineering-Maintenance | 50.000 EUR | 200.000 EUR | 250.000 EUR | | Marketing-Team-Aufwand | 30.000 EUR | 80.000 EUR | 110.000 EUR | | Performance / QA / A11y | 20.000 EUR | 60.000 EUR | 80.000 EUR | | Gesamt | 410.000 EUR | 620.000 EUR | 1.030.000 EUR |

Das ist kein Pessimismusszenario. Das sind realistische Mittelwerte aus vergleichbaren Stack-Setups. Der Business-Case, der nur die 250.000 EUR Implementierung betrachtet, unterschätzt den 5-Jahres-TCO um Faktor 4.

Wo Managed Platforms den TCO senken

Nicht alle Kostenposten sind fix. Die größte Hebelwirkung auf den 5-Jahres-TCO haben Entscheidungen, die den Engineering-Maintenance-Aufwand reduzieren:

Frontend-as-a-Service statt Self-Hosting. Eine Frontend Management Platform die das Hosting, die CI/CD-Pipeline, das Performance-Monitoring und die Security-Updates verwaltet, eliminiert den Großteil des Self-Hosting-Overheads. Laioutr-Customers berichten von einem LCP-Median von 1,2 Sekunden ohne dedizierten Performance-Engineering-Aufwand.

Integrated Studio für Marketing-Autonomie. Wenn Marketing neue Seiten und Kampagnen selbst im Editor aufbauen kann, ohne Engineering-Ticket, reduziert das den Opportunity-Cost-Posten erheblich. Das setzt voraus, dass der Frontend-Layer einen echten Visual Page Builder hat, nicht nur einen groben Block-Editor.

Unified Data Layer über alle Backends. Wenn der Frontend-Layer einen einheitlichen Datenabstraktions-Layer mitbringt, reduziert sich der API-Breakage-Handling-Aufwand erheblich. Der Composable Headless Frontend von Laioutr beispielsweise normalisiert Daten aus 50+ Backends in ein frontend-seitiges Schema - ein Backend-Wechsel ändert dann nicht die Komponentenlogik.

Fragen für den nächsten Business-Case

Wenn ihr gerade einen TCO-Business-Case vorbereitet oder reviewt, sind das die Fragen, die zu oft fehlen:

1. Mit welcher Lizenz-Eskalation rechnen wir über 5 Jahre? Wenn die Antwort "mit den aktuellen Listenpreisen" ist, fehlt der Risikoaufschlag.

1. Wie viel Engineering-Zeit geht jährlich für Maintenance drauf? Wenn die Antwort "minimal" ist, ohne konkrete Zahlen, fehlt eine zentrale Kostenposition.

1. Was kostet ein A11y-Nachrüstungssprint, wenn wir BFSG-konform werden müssen? Für nicht a11y-konforme Frontends ist das keine theoretische Frage.

1. Wie viele Engineering-Tickets generiert das Marketing-Team pro Quartal für Frontend-Änderungen? Das ist der direkte Indikator für die Marketing-Agilität des aktuellen Stacks.

1. Was passiert, wenn Vendor X seinen Preis verdoppelt oder sein Produkt einstellt? Das ist der Vendor-Lock-in-Risikoposten.

Fazit: TCO denkt in 5 Jahren, nicht in Sprints

Der Composable-Commerce-Ansatz ist wirtschaftlich sinnvoll, wenn er richtig kalkuliert wird. Die Implementierungskosten sind der sichtbarste Teil. Die Maintenance-Kosten, die Lizenz-Eskalation und der Engineering-Overhead für einen heterogenen Stack sind die Teile, die Business-Cases oft unter den Tisch fallen lassen.

Ein realistischer 5-Jahres-TCO hilft Teams, die richtigen Entscheidungen zu treffen: Managed-Platform vs. Self-Hosting, integrierter Visual Builder vs. CMS-Schicht, einheitlicher Datenlayer vs. System-by-System-Integration.

Weiterführende Links

• Composable Headless Frontend - Architektur-Layer und Backend-Orchestrierung
• Was ist eine Frontend Management Platform? - FMP-Kategorie und TCO-Implikationen
• Composable Visual Page Builder - Marketing-Autonomie und Engineering-Overhead-Reduktion
• Performance und Core Web Vitals - Performance-Monitoring eingebaut, kein separater Kostenposten
• Laioutr Platform UI - Frontend-as-a-Service als TCO-Hebel