Wer 2026 ein Digital Experience Platform einkauft, vergleicht in der Regel zuerst eines: die jährliche Lizenz. Preis pro Seat, pro API-Call, pro Pageview. Das wirkt rigoros, weil Procurement-Teams diese Disziplin perfekt beherrschen. Und genau hier beginnt das eigentliche Problem. Die Lizenz ist nicht der Kostenblock, der ein DXP-Programm in den nächsten fünf bis sieben Jahren prägt. Sie ist die kleinste, sichtbarste und am leichtesten verhandelbare Position auf einer langen Kostenliste, die kaum jemand vor der Vertragsunterschrift komplett aufschreibt.
Die Folge sieht in fast jeder Organisation gleich aus. Zwölf bis achtzehn Monate nach Go-Live laufen Year-2- und Year-3-Budgets aus dem Ruder, oft 40 bis 100 Prozent über Plan. Marketing-Kampagnen verzögern sich, Personalisierungsstrategien stehen im Backlog, und am Ende fragt ein CFO zurecht, was eigentlich der Return ist auf eine siebenstellige Investition. McKinsey hat 233 Senior-Marketing- und Technology-Leader befragt, die jeweils mehr als 500.000 USD pro Jahr in Martech und Adtech stecken. Keine einzige Person konnte den ROI dieser Ausgaben sauber artikulieren. Das ist kein individuelles Versagen. Das ist eine strukturelle Lücke, und sie entsteht in dem Moment, in dem ein DXP nur über die Lizenzkennzahl bewertet wird.
In diesem Beitrag schauen wir uns an, woraus DXP Total Cost of Ownership tatsächlich besteht, warum klassische Vergleichstabellen die wichtigsten Kostentreiber unsichtbar lassen, und welche architektonische Stellschraube wir bei Laioutr für den unterschätzten Hebel halten: den Frontend-Layer.
Wenn man in eine ehrliche TCO-Rechnung über drei bis fünf Jahre einsteigt, machen Lizenz- oder Subscription-Fees üblicherweise 25 bis 35 Prozent des gesamten finanziellen Commitments aus. Die übrigen 65 bis 75 Prozent verteilen sich auf Implementierung, Integration, Entwicklerstunden, Wartung, Governance und organisatorisches Change Management. Gartner-Schätzungen zeigen, dass rund 85 Prozent des Aufwands in einem DXP-Programm in Integration fließen: das Verbinden von Content-Management, Commerce, Analytics, Personalisierung, DAM und CDP zu einem funktionierenden Ganzen.
Das heißt: Die Frage "Welches DXP ist günstiger?" ist falsch gestellt, wenn sie nur Lizenzlisten gegeneinanderlegt. Die richtige Frage lautet: "Welche Architektur produziert über fünf Jahre den niedrigsten operativen Aufwand bei höchstem Output-Tempo?" Diese Frage beantwortet keine Lizenz-Pricing-Page. Sie beantwortet ein Architektur-Audit.
Die Posten, die nach dem Go-Live auftauchen, sind nicht statisch. Sie kompoundieren sich. Wir sehen in der Praxis vier Kostenkategorien, die jedes Lizenzkalkül zerlegen.
Jede Verbindung zwischen einem DXP und einem angrenzenden System wird zu einem eigenen Projekt mit eigenem Zeitplan, eigenem Budget und eigenem Wartungsaufwand. Produktinformationen, digitale Assets, Kundendaten, Analytics, Search, Personalization, Loyalty: für jeden dieser Bausteine entsteht eigenständige Integrationsarbeit. Architekturen, die für jede Verbindung Custom-Code erfordern, schaffen einen permanenten Entwicklungs-Overhead, der mit jedem zusätzlichen System wächst statt schrumpft. Wer einmal in dieser Falle steckt, finanziert nicht mehr Customer Experience, sondern Klebstoff.
Plattform-Upgrades, Security-Patches, Compliance-Updates und Browser-Releases binden dauerhaft Ressourcen. Klassische, monolithische DXPs zwingen ihre Kunden in Major-Upgrade-Zyklen, die ein Engineering-Team über Monate komplett auslasten können, ohne dass sich am Frontend ein einziger neuer Wert für den Endkunden zeigt. Composable-Architekturen verteilen die Wartung auf einzelne Services, was Single-Point-Disruption reduziert, aber bewusste Governance verlangt. Ohne klare Zuständigkeiten und Update-Routinen driftet ein composable Stack genauso schnell wie ein Monolith, nur in mehr Richtungen.
Spezialisierte Plattform-Entwickler kosten in 2026 Premium-Stundensätze, ob fest angestellt oder über Systemintegratoren eingekauft. Wenn diese Spezialisten gehen, verschwindet das institutionelle Wissen über Custom-Integrationen und Konfigurationen mit ihnen. Replacement-Hiring oder Onboarding kostet Monate reduzierter Velocity. Die Folge: Plattform-Knowhow konzentriert sich auf wenige Köpfe, die Verhandlungsposition kippt, und ein Burn-out-Risiko wird zum operativen Risiko.
Marketing-Kampagnen, die ihr Zeitfenster verpassen. Personalisierungsstrategien, die in einem JIRA-Ticket sterben. Produkt-Launches, die ein Quartal verschoben werden, weil das Frontend nicht so schnell publishbar ist wie das Business braucht. Diese Kosten erscheinen niemals auf einer Bilanz und kompoundieren sich trotzdem schneller als jede andere Position. Wer drei Quartale Time-to-Market verliert, verliert einen relevanten Marktanteil, ohne dass eine einzige Rechnung höher wird.
Die wichtigste Erkenntnis aus dutzenden Implementierungen, die wir begleitet haben, ist diese: Die Architektur, für die ein Unternehmen sich bei der Plattformauswahl entscheidet, legt die Kostenkurve für die nächsten fünf bis sieben Jahre fest. Eng gekoppelte, monolithische Plattformen erzeugen mit jedem zusätzlichen Use-Case zusätzliche Reibung, weil jede neue Integration durch dieselbe enge Schnittstelle muss. Modulare, composable Ansätze erlauben es Teams, einzelne Capabilities auszutauschen oder hinzuzufügen, ohne den ganzen Stack neu zu bauen.
Diese Trajektorie ist messbar. Im Jahr 1 sehen die Zahlen für Monolith und Composable noch ähnlich aus, der Composable-Stack wirkt sogar oft teurer wegen mehr involvierter Tools. Ab Jahr 2 spreizt sich die Kurve. Composable-Architekturen profitieren von linearen oder degressiven Wartungskosten pro Capability, weil Updates und Releases pro Service stattfinden. Monolithen kompoundieren ihre Major-Upgrade-Zyklen, ihre Custom-Integrationen und ihre Vendor-Lock-ins. Bis Jahr 5 ist der Unterschied so groß, dass keine Lizenzverhandlung ihn mehr kompensieren kann.
In den meisten DXP-Diskussionen geht es um Backend-Themen: CMS, Commerce-Engine, CDP, Personalization-Engine. Was selten passiert: Der Frontend-Layer wird als eigenständiger TCO-Treiber betrachtet. Aus unserer Erfahrung ist genau dort der unterschätzte Hebel.
Der Grund ist einfach. Das Frontend ist die Stelle, an der alle anderen Systeme zusammenlaufen müssen, damit ein Kunde eine Experience sieht. Jede Integration, jede Personalisierungslogik, jedes Multi-Market-Routing, jede A/B-Test-Variante wird im Frontend ausgespielt. Das bedeutet: Die meisten echten Integrationskosten und die meisten Wartungs-Tickets eines DXP entstehen am Frontend. Wer das Frontend als monolithisches Custom-Build betrachtet, kompoundiert seine TCO-Kurve. Wer das Frontend als austauschbaren, gemanagten Layer betrachtet, schneidet sie ab.
Ein gemanagtes Frontend-Layer-Modell senkt TCO an drei Stellen gleichzeitig. Erstens reduziert es die Tickets, die Marketing-Teams an Engineering geben müssen, weil Routine-Aufgaben wie Layout-Anpassungen, Komponenten-Tausch oder Kampagnenseiten visuell zusammengebaut werden können. Zweitens entkoppelt es die Frontend-Wartung von der Backend-Plattform, was Upgrade-Risiken minimiert. Drittens reduziert es die Talent-Abhängigkeit, weil weniger spezialisierte Plattform-Frontend-Entwickler dauerhaft an Bord sein müssen.
Eine seriöse DXP-Evaluierung beginnt nicht mit Lizenzkosten, sondern mit einer Fünf-Jahres-Modellierung der operativen Gesamtkosten. Folgende Posten gehören in jedes Modell.
Implementierungskosten inklusive Integration mit allen relevanten Adjacent-Systems, nicht nur mit dem Backend, an das gerade jemand denkt. Laufende Wartungskosten differenziert nach Plattform, Integration, Frontend und Compliance. Talent-Kosten in einem Drei-Szenario-Modell: optimal besetzt, durchschnittliche Fluktuation, Krisen-Szenario. Governance- und Change-Management-Kosten, weil eine composable Architektur ohne Spielregeln teurer wird als ein Monolith mit Spielregeln. Opportunity Cost als Velocity-Kennzahl: Wie viele Tage Time-to-Market schenkt oder kostet die Plattform pro Kampagne?
Diese Modellierung ist anstrengend. Sie ist aber das einzige Werkzeug, mit dem ein Vorstand eine seriöse Aussage darüber machen kann, ob ein DXP-Investment in fünf Jahren ein Wachstumsmotor oder ein Sunk Cost wird.
Die nächste DXP-Auswahl im Unternehmen sollte nicht mit der Frage beginnen, welche Lizenz günstiger ist. Sie sollte mit der Frage beginnen, welche Architektur in fünf bis sieben Jahren den niedrigsten operativen Aufwand bei höchster Markt-Velocity erzeugt. Die Lizenzposition ist verhandelbar, aber sie ist klein. Integration, Wartung, Talent, Architektur und Opportunity Cost sind groß und kompoundieren sich.
Wer diesen Perspektivwechsel intern durchsetzen kann, gewinnt schon vor der Vertragsunterschrift. Und wer den Frontend-Layer als eigenständigen, gemanagten Hebel begreift, schneidet die TCO-Kurve genau an der Stelle ab, an der sie für die meisten Organisationen außer Kontrolle gerät.
Lizenz- und Subscription-Fees machen typischerweise 25 bis 35 Prozent der gesamten DXP-Total Cost of Ownership über drei bis fünf Jahre aus. Die verbleibenden 65 bis 75 Prozent entfallen auf Integration, Entwicklerressourcen, laufende Wartung, Governance und organisatorisches Change Management. Wer DXPs nur über Lizenzpreise vergleicht, blendet die Mehrheit der finanziellen Verpflichtung aus.
Die meisten Organisationen erleben die erste signifikante Kosteneskalation zwölf bis achtzehn Monate nach Go-Live. Zu diesem Zeitpunkt fallen Integrationswartung, Plattform-Upgrades und Spezialisten-Bindung gleichzeitig an. Year-2- und Year-3-Budgets liegen häufig 40 bis 100 Prozent über den ursprünglichen Schätzungen, besonders in Architekturen, die Custom-Code für jede Systemverbindung benötigen.
Der Frontend-Layer ist die Stelle, an der alle Backend-Systeme einer DXP-Architektur sichtbar zusammenlaufen. Integrationen, Personalisierung, A/B-Tests und Multi-Market-Routing werden im Frontend ausgespielt. Damit konzentrieren sich dort die meisten Wartungs-Tickets und Custom-Code-Kosten. Ein gemanagter, austauschbarer Frontend-Layer senkt Tickets, entkoppelt Upgrades und reduziert Talent-Abhängigkeit.
Beim Full-Platform-Replacement wird das bestehende DXP komplett entfernt und auf einer composable Architektur neu aufgebaut. Ein Composition Layer setzt auf bestehende Systeme auf und verbindet vorhandene CMS, DAM, CDP und Commerce-Tools in einer einheitlichen Orchestrierungsumgebung, ohne forced Migration. Beide Ansätze senken Integrations-Overhead. Welcher passt, hängt von technischer Schuld, Zeitplan und Restwert vorhandener Investments ab.
Erfahrene Partner bringen Muster-Wissen aus dutzenden Implementierungen mit und erkennen, welche Architekturentscheidungen Folgekosten erzeugen und welche stabile Operating-Models schaffen. Ihr Wert konzentriert sich in der Evaluations- und Architekturphase. Eine einzige fundierte Entscheidung zur Integrationsstrategie kann sechsstellige Folgekosten in Year 2 bis Year 5 verhindern.
Zeig uns Deinen Stack, Deine Roadmap, Dein Replatforming-Szenario, wir zeigen Dir, wie Laioutr passt, was es kostet und wie schnell ihr live geht.
"Nach 30 Minuten wussten wir, dass Laioutr unser Replatforming machbar macht." - Daniel B., CEO, hygibox.de