Storytelling-PDPs vs. Spec-Sheets: der DACH-Conversion-HebelDie meisten DACH-Mid-Market-Product-Deta…
MarTech-Konsolidierung 2026: wo der Frontend-Layer gewinnt
MarTech-Konsolidierung 2026: wo der Frontend-Layer gewinnt
Contentful hat am 20. Mai 2026 "Skills" angekündigt, einen AI-Coding-Agent direkt im CMS. Auf den ersten Blick ein nützliches Werkzeug. Auf den zweiten Blick ein Markt-Signal: jeder etablierte Tool-Anbieter im MarTech-Stack legt 2026 einen AI-Layer dazu. Mein Take als CEO eines Mid-Market-Frontend-Anbieters in DACH ist unbequem: jeder zusätzliche AI-Adapter auf einem bestehenden Stack erhöht die Integrations-Steuer, nicht den Wert. Die Antwort für Mid-Market-Commerce 2026 ist nicht "mehr Layer", sondern "weniger Layer".
Dieser Artikel ist kein Contentful-Bashing. "Skills" wird hier als das zitiert, was es ist: ein Markt-Signal, das eine bestimmte Kategorie-Frage aufmacht. Die Frage lautet: wo entstehen in eurem MarTech-Stack heute Maintenance-Costs, die ihr in der TCO-Rechnung von 2024 nicht hattet? Und wo könnt ihr Stack-Konsolidierung als Hebel nutzen, statt der nächsten Adapter-Logik nachzukaufen?
Die Stack-Sprawl-Steuer, die niemand budgetiert
Schaut auf einen typischen DACH-Mid-Market-Commerce-Stack im Frühjahr 2026. Ein Backend (Shopware, commercetools, Salesforce Commerce, Adobe Commerce). Ein CMS (Contentful, Storyblok, Adobe Experience Manager). Ein Search-Layer (Algolia, Bloomreach, Constructor). Ein Personalization-Tool (Dynamic Yield, Bloomreach Discovery, eigene Engine). Ein Visual-Editor (Builder.io, Mosaic von Storyblok, Optimizely Web). Ein Analytics-Stack (Amplitude, Mixpanel, GA4). Ein Frontend-Framework und eine eigene Build-Pipeline.
Sieben bis neun Tools, von denen jedes inzwischen einen AI-Adapter angekündigt oder schon ausgeliefert hat. Jeder Adapter kostet Engineering-Time für die Integration, Pflege bei API-Versionswechseln, Onboarding für jedes neue Team-Mitglied, ein eigenes SLA-Verständnis bei Outages. Das ist keine Sprint-Story, das ist eine strukturelle Stack-Sprawl-Steuer. Auf einen Mid-Market-Setup geschätzt: 12 bis 25 Prozent der Engineering-Kapazität pro Quartal fließen in Tool-Integration und Maintenance, nicht in Feature-Arbeit. Wir sehen diese Zahl quer durch unsere DACH-Discovery-Gespräche, und sie schwankt nur leicht zwischen Branchen.
Die Steuer wird selten als eigene Position budgetiert. Sie versteckt sich in "Engineering-Capacity", in "DevOps-Cost" und in der dritten Zeile eures Tool-TCO-Reports. Genau deshalb fällt sie der Procurement-Diskussion regelmäßig zum Opfer: was nicht als Position erscheint, wird nicht verglichen.
Warum jeder neue AI-Adapter die Steuer erhöht
Die marketingseitige Logik hinter Adaptern wie Contentful Skills ist nachvollziehbar: der Vendor sagt seinem Customer, "ihr braucht euch nicht zu bewegen, wir bringen AI zu euch". Das löst kurzfristig ein Problem (AI-Funktionalität ohne Tool-Wechsel), schafft aber mittelfristig drei neue:
Integrations-Overhead pro Adapter. Jeder AI-Adapter ist ein eigenes Datenmodell, ein eigenes Auth-Schema, ein eigenes Webhook-Setup. In einem Stack mit acht Tools heißt das im Schnitt vier bis sechs aktive AI-Adapter über die nächsten 18 Monate, jeder mit eigenem Maintenance-Cost.
Datensilo-Verstärkung. Der AI-Adapter im CMS sieht das CMS-Datenmodell. Der AI-Adapter im Search-Tool sieht den Suchindex. Der AI-Adapter im Personalization-Tool sieht die Session-Daten. Niemand sieht den vollständigen Customer Journey, weil die Adapter über Tool-Grenzen hinweg nicht reden. Konsequenz: jeder AI-Output bleibt in der Silo-Logik des Hosts.
Versions-Lock-in. Wer in einen Tool-AI-Adapter investiert, ist auf den Release-Zyklus des Hosts angewiesen. Was Contentful Skills im Q3 2026 kann, ist nicht das, was ihr 2027 braucht. Das Risiko ist nicht der Tool-Wechsel, sondern die Tool-AI-Funktionalität, die sich nicht so weiterentwickelt, wie euer Use-Case es bräuchte.
Das ist keine Häme gegen Contentful oder gegen Skills. Es ist die strukturelle Konsequenz, einen AI-Layer auf ein Tool zu legen, dessen Wert-Versprechen "Content-Management" lautet, nicht "Composition-Layer für Commerce".
Stack-Audit als CFO-Frage: wo könnt ihr konsolidieren?
Hier wird der Take CFO-relevant. Wenn ihr in den nächsten 12 Monaten mit einem MarTech-Renewal konfrontiert seid, sollte die Frage nicht lauten "verlängern wir Tool X?". Sie sollte lauten: welche drei Tools in eurem Stack lösen heute überlappende Probleme, und welcher davon ist der teuerste in der Maintenance?
Konkrete Beispiele aus unseren Discovery-Gesprächen mit Mid-Market-Buyern (B2C-Fashion bis B2B-Spareparts, alle DACH):
Beispiel 1. Ein Stack mit Storyblok (CMS), Builder.io (Visual-Editor), eigenem Frontend-Framework. Drei Tools, eine Aufgabe: Pages aus Komponenten komponieren. Konsolidierung auf einen Frontend-Layer ersetzt zwei davon, ohne dass das Backend-CMS verschwindet. Erwarteter TCO-Effekt nach 18 Monaten: 30 bis 45 Prozent Tool-Cost-Reduktion plus 8 bis 15 Prozent zurückgewonnene Engineering-Capacity.
Beispiel 2. Ein Stack mit Dynamic Yield (Personalization), separatem A/B-Tool, separatem Visual-Editor. Drei Tools, eine Marketing-Aufgabe: Layout-Variation pro Segment. Konsolidierung auf einen Frontend-Layer mit integriertem Variant-Editor reduziert die Personalisierungs-Toolchain auf eines plus ein Audience-Tool für die Segmente.
Beispiel 3. Ein Stack mit drei AI-Adaptern (CMS-AI, Search-AI, Editor-AI), die jeweils kostenpflichtig sind. Konsolidierung auf einen Frontend-Layer, der seine eigene AI-Funktionalität liefert, ersetzt mindestens zwei der Adapter-Lizenzen.
In allen drei Fällen ist die Konsolidierungs-Frage nicht "ersetzen wir das CMS?", sondern "ersetzen wir den Composition-Layer". Das CMS bleibt. Das Backend bleibt. Was geht, ist die Schicht zwischen Backend-Daten und Browser-Output, die heute auf drei bis fünf Tools verteilt ist.
Die Frontend-Management-Platform als Konsolidierungs-Hebel
Eine Frontend Management Platform (FMP) ist die Antwort auf diese Konsolidierungs-Frage. Sie ersetzt nicht das CMS, sie ersetzt die Schichten zwischen CMS und Browser, die heute typischerweise aus Visual-Editor plus Personalization plus eigenem Build-Layer bestehen. Sie integriert in beliebige Backends (CMS, Commerce, PIM, Search), bietet Marketern einen Studio-Editor zur Komposition und Auslieferung in Stunden statt Sprints, und reduziert die Engineering-Maintenance auf einen Vendor statt drei.
Was bedeutet das in der TCO-Rechnung? Vereinfacht und auf einen Mid-Market-DACH-Setup gerechnet:
- Position | Status-quo-Stack (3-5 Tools) | FMP-Konsolidat
- Lizenz-Cost (Annual) | 180-320k Euro | 90-160k Euro
- Engineering-Maintenance (FTE-Equivalent) | 0.8-1.5 FTE | 0.2-0.5 FTE
- Iterations-Zeit (Pro Layout-Change) | 2-6 Sprint-Slots | Studio-Live (gleicher Tag)
- Onboarding pro neuem Team-Member | 2-3 Wochen (mehrere Tools) | 3-5 Tage (ein Tool)
Die exakten Zahlen variieren stark nach Vertrag, Lizenz-Volumen und Engineering-Setup. Was nicht variiert ist die Richtung: Konsolidierung reduziert die Stack-Sprawl-Steuer, ohne dass Backend-Wechsel notwendig ist. Das ist der entscheidende Punkt für CFOs, die ein 18-Monats-Replatforming-Risiko nicht eingehen wollen.
Was das für eure nächste Renewal-Entscheidung bedeutet
Drei konkrete Schritte, die ihr im nächsten Quartal anstoßen könnt, ohne sofort einen Tool-Wechsel zu committen:
Stack-Audit mit Maintenance-Cost-Lens. Listet alle MarTech-Tools mit Lizenz-Cost UND Engineering-FTE-Equivalent für Integration und Pflege. Sortiert nach Total-Cost, nicht nach Lizenz-Cost. Die Reihenfolge sieht typischerweise anders aus als das, was Procurement im Vendor-Vergleich zeigt.
Overlap-Mapping. Markiert Tools, die mehr als eine Funktion erfüllen, und Funktionen, die mehrfach besetzt sind. Drei Tools, die "Layout-Komposition" als eine ihrer Funktionen führen, ist ein Konsolidierungs-Kandidat.
Renewal-Window-Planung. Wenn euer CMS-Renewal im Q4 ansteht und das Visual-Editor-Renewal im Q1, ist das Konsolidierungs-Fenster Q4 bis Q1 zusammen. Plant nicht zwei Renewals einzeln, sondern eine Stack-Entscheidung über beide.
Closing: das Markt-Signal lesen, nicht den Adapter kaufen
Contentful Skills ist nicht das Problem. Skills ist ein gut gebautes Werkzeug für eine Kategorie, die Contentful klar besetzt: AI-Layer auf bestehende CMS-Workflows. Das Markt-Signal ist breiter: jeder etablierte MarTech-Vendor antwortet 2026 auf den AI-Druck mit einem eigenen Adapter, und das Aufeinander-Stapeln von Adaptern ist genau die Bewegung, die die Stack-Sprawl-Steuer erhöht.
Die Mid-Market-Antwort für 2026 ist nicht "kaufe den nächsten Adapter", sondern "audite den Composition-Layer". Wenn ihr dort konsolidieren könnt, gewinnt ihr zwei Dinge gleichzeitig: niedrigere TCO und höhere Iterations-Geschwindigkeit. Das ist der Hebel, den ein Frontend-Layer-Konsolidat heute leise auslöst, während die Aufmerksamkeit auf den AI-Adaptern liegt.
Weiterlesen:
CTA: Wenn ihr euren Stack im nächsten Quartal auditieren wollt, buche ich gerne ein 30-Minuten-Stack-Audit mit euch. Ihr bekommt eine konkrete Overlap-Karte, keine Demo-Slide.