Auf dem eCommerce BBQ 2026 fiel ein Satz, der die Stimmung des Abends auf den Punkt brachte: Gestern…
Die Zukunft des E-Commerce: Warum Adaption nicht reicht und Evolution im Frontend beginnt
Auf dem eCommerce BBQ 2026 fiel ein Satz, der die Stimmung des Abends auf den Punkt brachte: Gestern haben wir im E-Commerce gemacht, was ging. Morgen machen wir, was wertschöpfend ist. Griffig formuliert, aber eine unbequeme Ansage, sobald man ehrlich auf den eigenen Stack schaut.
Denn so sind die meisten Shops gebaut. Über Jahre wurde angebaut, was gerade möglich war: ein Tool hier, eine Integration da, ein weiteres Feature obendrauf. Das Ergebnis läuft, aber es ist selten das Ergebnis einer Entscheidung. Es ist das Ergebnis vieler kleiner Anpassungen.
Dieser Beitrag nimmt den Kerngedanken des Abends auf und denkt ihn aus Frontend-Sicht weiter: Warum Adaption nicht dasselbe ist wie Evolution, warum der Tool-Turm an seine Grenze kommt, und warum der Storefront-Layer der Ort ist, an dem im E-Commerce künftig die Wertschöpfung entsteht.
Der Markt wächst wieder, doch die Spielregeln verschieben sich
Zuerst die Fakten. Der deutsche Onlinehandel ist zurück im Wachstum. Laut IFH Köln legt der Markt 2025 um bis zu 5,7 Prozent zu, nach 3,8 Prozent im Vorjahr. Das sind rund 92 Milliarden Euro Umsatz mit Neuware, gut 103 Milliarden Euro inklusive Secondhand. Für 2026 zeigt die Kurve weiter nach oben.
Gutes Wachstum also. Nur sagt Wachstum allein nichts darüber, wer davon profitiert. Während der Markt wächst, verschiebt sich darunter etwas Grundlegendes, und das hat einen Namen: KI.
KI ist im E-Commerce nicht das nächste Tool in der Reihe. Bisher lief jede neue Technologie nach demselben Muster ab: Sie taucht auf, und wir fragen, wie wir sie in unser bestehendes Geschäftsmodell einbauen. Bei KI greift dieses Muster zu kurz. Die spannendere Frage lautet nicht, wie wir KI an unser Modell anpassen, sondern welcher Teil unseres Modells durch KI überflüssig wird. KI verändert nicht ein Feature. KI verändert, wo und wie im Handel Wert entsteht.
Adaption ist nicht Evolution
Hier liegt der Denkfehler, der teuer wird. Adaption heißt: Wir nehmen das Neue und passen es an das Alte an. Evolution heißt: Wir bauen das Alte um, weil das Neue die Grundlage verändert hat.
Henry Ford hat den Unterschied auf den Punkt gebracht. Hätte er seine Kunden gefragt, was sie wollen, hätten sie ein schnelleres Pferd verlangt. Auf den heutigen Handel übertragen: Wer seinen bestehenden Stack nur optimiert, bekommt einen stabileren Turm, kein neues Fundament. Das Bild vom Hamster trifft es ebenfalls. Im Laufrad rennen ist Aktivität, die Leiter hochsteigen ist Fortschritt. Von außen sieht beides nach Bewegung aus. Nur eines bringt dich nach oben.
Die ehrliche Frage aus dem eCommerce BBQ war deshalb keine Tech-Frage, sondern eine Geschäftsfrage: Welcher Teil eures Setups hält nur deshalb zusammen, weil ihr es immer so gemacht habt?
Das eigentliche Problem: E-Commerce als Tool-Turm
Schaut man auf einen typischen Stack, sieht man oft das gleiche Bild. Unten der Onlineshop, darüber gestapelt: PIM, Suche, A/B-Testing, Analytics, CRM, Personalisierung, Payments, Marketing-Automation. Jede Schicht ein eigenes Tool, jedes Tool eine eigene Integration, jede Integration eine eigene Datensynchronisation.
Dieser Turm funktioniert, solange niemand daran wackelt. Aber er ist fragil, teuer und schwer skalierbar. Jede neue Fähigkeit kostet eine weitere Schnittstelle und einen weiteren Punkt, an dem etwas brechen kann. Wer hier ein Feature austauschen will, zieht selten einen einzelnen Stein heraus, ohne dass der ganze Aufbau nachgibt.
Genau das ist Adaption in Reinform. Über Jahre wurde angebaut, was ging, und am Ende verwaltet das Team mehr Integrationen als Inhalte. Die Komplexität ist nicht das Mittel zum Umsatz, sie ist die Steuer, die der Umsatz zahlt.
Woran ihr erkennt, dass ihr noch adaptiert
Der Übergang von Adaption zu Evolution ist selten ein einzelner großer Moment. Meistens verrät er sich an Kleinigkeiten im Alltag. Drei Signale tauchen dabei immer wieder auf.
Erstens: Eine einfache Landingpage braucht ein Entwickler-Ticket und wartet im Sprint-Backlog. Wenn Marketing für eine Kampagnenseite auf Engineering angewiesen ist, steht die Wertschöpfung im Stau.
Zweitens: Niemand traut sich, ein Tool auszutauschen. Wenn die Antwort auf die Frage, ob ihr die Suche wechseln könnt, regelmäßig "theoretisch ja, praktisch lieber nicht" lautet, regiert der Turm das Team und nicht umgekehrt.
Drittens: Ein neuer Markt oder eine neue Marke bedeutet jedes Mal ein Projekt von vorn. Eine evolutionäre Architektur rollt zusätzliche Marken und Märkte aus einer Basis aus, statt sie zu duplizieren.
Wer sich in einem dieser Punkte wiedererkennt, hat nichts falsch gemacht. Es ist die normale Folge davon, über Jahre angebaut zu haben, was ging. Der Punkt ist nur: Optimieren macht den Stau kürzer, Entkoppeln löst ihn auf.
Die Evolution passiert im Frontend
Die gute Nachricht: Der Ausweg ist keine größere Suite und kein noch höherer Turm. Der Ausweg liegt in einer klaren Trennung von zwei Ebenen.
Das Backend wird zur Stelle der Wahrheit. Produkte, Bestände, Bestellungen, Preise leben dort, sauber und einmal gepflegt. Das Frontend wird zum Ort, an dem aus diesen Daten Kundenwert entsteht: Geschwindigkeit, Content, Personalisierung, Conversion. Zwischen beiden steht ein entkoppelter Storefront-Layer, der die Daten konsumiert und das Erlebnis komponiert.
Ein Satz vom Event bringt diese Verschiebung auf den Punkt: Früher waren Onlineshops technische Projekte, heute sind sie kaufmännische Projekte. Übersetzt heißt das, der Frontend-Layer ist kein nachgelagertes Implementierungs-Thema mehr. Er ist der Hebel für Marketing-Geschwindigkeit, Markteintritt und Conversion. Genau deshalb gehört er nicht ans Ende der Kette, sondern ins Zentrum der Architektur. Wie dieser entkoppelte Layer in der Praxis aussieht, zeigen wir auf unserer Seite zum Composable Headless Frontend.
Evolution heißt nicht, einen Monolithen gegen den nächsten zu tauschen
An dieser Stelle lauert die Versuchung, alles wieder in ein einziges geschlossenes System zu pressen. Das fühlt sich nach Aufräumen an, baut aber nur den Turm mit schöneren Wänden neu und erzeugt die nächste Abhängigkeit. Ein Monolith bleibt ein Monolith, auch wenn er modern aussieht.
Unsere Sicht ist eine andere. Evolution im Frontend bedeutet Composable, nicht geschlossen. Eine Frontend Management Platform (FMP) bündelt die conversion-relevanten Fähigkeiten in einer Steuerungsebene, ohne das Backend zu schlucken. Die Architektur bleibt offen, die Datenhoheit bleibt in eurer Hand, und der Stack bleibt austauschbar. Wer den Vergleich zur klassischen Suite sucht, findet ihn auf unserer Seite zur Composable Digital Experience Platform.
Der Unterschied ist nicht kosmetisch. Beim Monolithen kauft ihr Bequemlichkeit gegen Bindung. Bei Composable behaltet ihr die Kontrolle über jede Schicht und könnt einzelne Bausteine wechseln, ohne das Gesamtsystem anzufassen.
Was eine evolutionäre Frontend-Architektur leistet
Die Fähigkeiten, die heute über zehn lose verbundene Tools verstreut sind, gehören in den Storefront-Layer, an einem Ort steuerbar. Konkret heißt das:
- Personalisierung, die direkt im Edge-Rendering greift, statt als Skript nachgeladen zu werden.
- A/B-Testing und Optimization, bei dem die Variante schon live ist, bevor sie ausgespielt wird, ohne Performance-Verlust.
- Content und Page-Composition im Visual Page Builder, sodass Marketing neue Landingpages in Stunden statt Wochen baut.
- SEO und GEO mit sauberem Schema.org-Markup, damit der Storefront auch in KI-Antworten sichtbar bleibt.
- Performance und Core Web Vitals als Architektur-Eigenschaft, nicht als nachträgliche Optimierung.
- Multi-Brand und Multi-Market, damit neue Marken und Märkte aus einer Basis ausrollen.
- Barrierefreiheit nach WCAG, eingebaut statt nachgerüstet, mit Blick auf das BFSG.
Der praktische Effekt: Marketing-Teams iterieren selbst, Engineering reviewt und erweitert. Kein Banner-Ticket mehr, das eine Woche im Sprint-Backlog liegt. Aus dem fragilen Turm wird eine Steuerungsebene, die schnell, stabil und conversion-stark ist.
Backend bleibt, Frontend wird frei
Der vielleicht wichtigste Teil der Evolution: Sie verlangt kein Replatforming. Ihr müsst euer Backend nicht austauschen, um euer Frontend zu modernisieren.
Ein entkoppelter Layer setzt sich oben auf den bestehenden Commerce-Stack. Ob Shopware, Shopify, commercetools, OXID oder Magento, das Backend bleibt die Stelle der Wahrheit, das Frontend wird frei. Damit minimiert ihr das klassische Replatforming-Risiko: kein Greenfield-Projekt über 18 Monate, sondern ein Frontend-First-Weg, bei dem das Backend später trotzdem austauschbar bleibt.
Die Anbindung weiterer Fähigkeiten läuft über offene Schnittstellen und fertige Connectoren statt über handgeschriebenen Glue-Code. Welche Integrationen und Apps sich anbinden lassen, seht ihr im Laioutr App Store. Das ist der entscheidende Unterschied zum Tool-Turm: nicht weniger Fähigkeiten, sondern weniger Bruchstellen.
Warum das im DACH-Markt besonders zählt
Im DACH-Raum kommen zwei Themen dazu, die für eine Entkopplung sprechen. Erstens Hosting und Datenschutz. EU-gehostet und DSGVO-konform sind hier keine Kür, sondern Voraussetzung. Eine entkoppelte Architektur macht es leichter, den Storefront-Layer dort zu betreiben, wo die Daten liegen sollen, ohne dass ihr dafür das Backend anfassen müsst.
Zweitens die Barrierefreiheit. Mit dem Barrierefreiheitsstärkungsgesetz (BFSG) wird Accessibility für viele Shops verpflichtend, und nachgerüstete Barrierefreiheit ist teuer. Ein Frontend, das WCAG von Beginn an mitdenkt, spart genau diese Nachrüstung. Beides ist kein Add-on, sondern eine Eigenschaft der Architektur, und damit ein weiteres Argument dafür, den Frontend-Layer bewusst zu wählen statt ihn über Jahre zusammenwachsen zu lassen.
Agentic Commerce: die nächste Stufe der Evolution
Wenn KI verändert, wo Wert entsteht, dann verändert sie auch, wer den Storefront bedient. Im Zeitalter von Agentic Commerce arbeiten Menschen und KI-Agenten an derselben Component-Library. AI Agents übernehmen konkrete Aufgaben: Content-Varianten erzeugen, Meta-Tags und interne Verlinkung optimieren, Core Web Vitals überwachen und bei Regression Alarm schlagen.
Zugleich verschiebt sich die Nachfrageseite. Immer häufiger recherchieren und kaufen Agenten im Auftrag von Menschen. Ein Storefront muss deshalb agent-ready sein: strukturierte Daten, sauberes Schema.org, klare APIs. Wer hier früh aufräumt, ist sichtbar, wenn die Anfrage nicht mehr von einem Browser kommt, sondern von einem Agenten. Genau dafür ist eine Agentic Frontend Management Platform gebaut.
Das ist keine ferne Vision. Es ist die logische Fortsetzung der Trennung von Backend und Frontend. Wenn der Storefront-Layer ohnehin der Ort der Wertschöpfung ist, dann ist er auch der Ort, an dem KI den größten Hebel hat.
Was das für dich heißt
Der Abend an der Spree endete mit einem Augenzwinkern auf das Ford-Zitat: Hätte man die Kunden gefragt, sie hätten sich nur einen stabileren Turm gewünscht. Die Pointe gilt für den ganzen Markt. Ein stabilerer Turm ist Adaption. Ein neues Fundament ist Evolution.
Praktisch heißt das nicht, morgen alles neu zu bauen. Es heißt, mit der Frage anzufangen, wo bei euch Wert auf den Kunden trifft. Diese Stelle ist fast immer das Frontend. Genau dort lohnt sich der erste evolutionäre Schritt, weil er schnell sichtbar wird, das Backend nicht anfasst und das Replatforming-Risiko klein hält.
Der Markt wächst wieder. Die Frage ist nur, ob ihr im Laufrad schneller rennt oder die Leiter hochsteigt.
Wenn ihr wissen wollt, wie der erste Schritt für euren Stack aussieht, schaut auf laioutr.com vorbei oder lest weiter im Insights-Blog.