Jede ernstzunehmende E-Commerce-Plattform liefert heute eine eigene Frontend-Lösung mit. Shopify hat Hydrogen, SAP Commerce Cloud bringt Spartacus, commercetools verkauft commercetools Frontend (ehemals Frontastic), VTEX hat FastStore, BigCommerce setzt auf Catalyst, Adobe Commerce auf PWA Studio plus Edge Delivery, Shopware bietet Shopware Frontends. Auf den ersten Blick wirkt das wie ein klares Setup: Backend wählen, dazu das passende native Frontend nehmen, fertig.
In der Praxis stoßen DACH-Brands mit dieser Logik regelmäßig an drei Wände: das Frontend ist an genau ein Backend gebunden, der Custom-Build dauert sechs bis zwölf Monate, und Marketing-Teams brauchen für jede Landingpage ein Entwickler-Ticket. Genau deshalb entsteht gerade eine neue Kategorie: agentic Frontend-Management-Plattformen, die unabhängig vom Shop-System arbeiten und das Storefront-Rendering, Studio, UI-Library und KI-Operations in einer Plattform bündeln.
In diesem Beitrag schauen wir uns an, welche nativen Frontend-Lösungen die wichtigsten Shop-Systeme weltweit anbieten, wo deren Grenzen liegen und ab wann eine Composable-Frontend-Plattform die nachhaltigere Wahl ist.
Welche Shop-Systeme welche Frontend-Lösung mitbringen
Wir konzentrieren uns auf die zwölf Plattformen, die im DACH-Markt und international den größten Anteil ausmachen. Eine vollständige Übersicht inklusive Open-Source- und SMB-Plattformen findet sich am Ende des Beitrags.
Shopify und Shopify Plus liefern Liquid-Themes und Online Store 2.0 für den klassischen Storefront, plus Hydrogen (React) und Oxygen Hosting für Brands, die einen Headless-Stack auf Shopify betreiben wollen. Hydrogen ist tief mit Storefront API, Metaobjects und Shopify-eigenen Datenstrukturen verzahnt.
BigCommerce setzt auf Stencil-Themes für klassische Storefronts und Catalyst, einen offiziellen Next.js-Reference-Storefront für Composable-Setups. Catalyst ist relativ neu am Markt und positioniert sich als Headless-Antwort von BigCommerce.
Adobe Commerce / Magento kombiniert Luma-Themes (PHP-getrieben) mit PWA Studio (React-basiert) und Edge Delivery Services, die Adobe seit 2024 als ergänzenden Performance-Layer ausbaut. Die Komplexität dieses Stacks ist hoch, weil drei Render-Strategien parallel existieren.
Salesforce Commerce Cloud bietet SFRA (Storefront Reference Architecture) als klassischen Storefront und das Composable Storefront / PWA Kit als Headless-Pfad. Beide sind eng mit Salesforce-Identitäten und Customer-Datenmodell verbunden.
SAP Commerce Cloud liefert Spartacus als offizielles Composable Storefront. Spartacus ist Angular-basiert, fokussiert sich auf B2B- und Enterprise-Setups und benötigt typischerweise tiefe SAP-Hybris-Expertise im Team.
commercetools verkauft seit der Frontastic-Übernahme commercetools Frontend, ein Composable Storefront mit Studio und Backend-Integration für commercetools. Der Stack ist primär auf den eigenen Backend-Provider fokussiert.
Shopware bietet zwei Welten: das Shopware 6 Default Storefront (Twig/Symfony) für klassische Setups und Shopware Frontends (ehemals Shopware PWA) für Composable Brands. Letzteres ist React-basiert und zielt auf Headless-Projekte.
VTEX stellt mit VTEX IO und FastStore (vom IO-Team) eine Next.js-basierte Composable-Storefront-Lösung bereit. FastStore ist auf Performance optimiert und wird in Lateinamerika sehr breit eingesetzt.
Spryker kommt mit Yves als Default-Frontend (Twig) und einer Composable Frontend Reference, die für moderne B2B- und Enterprise-Architekturen gedacht ist.
Elastic Path bietet Elastic Path Studio plus eine Composable Frontend Reference Storefront für Brands, die in deren Composable-Stack einsteigen.
Saleor liefert eine Saleor Storefront Reference auf Next.js plus die Saleor Apps für Custom-Erweiterungen.
Medusa setzt auf einen Medusa Next.js Starter, der zusammen mit dem Medusa Admin als Open-Source-Stack vermarktet wird.
Daneben gibt es WooCommerce mit Storefront-Theme und WooCommerce Blocks, Centra mit Custom-Themes, Intershop mit eigener PWA, OroCommerce für B2B, Kibo Commerce, Vendure mit Storefront-Startern in Angular, React, Vue und Qwik, Sylius mit Symfony Twig sowie SaaS-Plattformen wie Wix Commerce, Squarespace Commerce, Ecwid und JTL-Shop, die jeweils eigene Theme-Engines mitbringen.
Wo alle nativen Frontends an die gleichen Grenzen stoßen
So unterschiedlich diese Frontend-Lösungen wirken, so ähnlich sind die Probleme, die DACH-Brands in der Praxis mit ihnen haben. Wir sehen das in jedem Sales-Gespräch und jeder Architektur-Bewertung.
Backend-Lock-in als Standard
Hydrogen funktioniert nur mit Shopify, Spartacus nur mit SAP Commerce Cloud, FastStore nur mit VTEX, Catalyst nur mit BigCommerce, commercetools Frontend nur mit commercetools. Sobald ihr Multi-Brand mit unterschiedlichen Backends fahrt, internationalisiert oder einen Backend-Wechsel plant, müsst ihr das Frontend neu aufsetzen oder mehrere Frontends parallel betreiben. Für Brands, die heute auf Shopify sind und morgen auf Shopware oder commercetools migrieren wollen, ist das ein Risiko, das Frontend-Investitionen verbrennen kann.
Dev-First-Architektur
Native Frontends sind im Kern Code-Repositories. Eine Marketing-Person, die eine neue Promo-Landingpage live bringen will, muss in den meisten Fällen ein Ticket bei der Engineering schreiben, auf einen Sprint warten, einen Deploy abwarten und sich dann durch ein Pull-Request-Review kämpfen. Das funktioniert in der Theorie, in der Praxis verzögert es Kampagnen um Wochen.
Implementierungs-Marathon
Custom-Builds auf Hydrogen, PWA Studio, Spartacus, Catalyst, FastStore oder Shopware Frontends laufen typischerweise sechs bis zwölf Monate. Brands brauchen ein Engineering-Team, das Erfahrung mit dem jeweiligen Framework hat (React, Next.js, Angular, Vue, Symfony Twig, je nach Plattform). Während dieser Bauphase entsteht kein Storefront-Wert, kein Conversion-Lift, kein neues Brand-Erlebnis. Die Investition rechnet sich erst nach Go-Live, oft nach Quartalen.
Fehlende KI-Integration auf Frontend-Ebene
Native Frontends bringen kaum agentische KI-Funktionen mit. Layout-Vorschläge, automatische Konversions-Optimierung, KI-gestützte Content-Synchronisation über Märkte oder ein Storefront-übergreifender Agent sind in nativen Frontends Custom-Entwicklung. Wer KI als Plattform-Feature braucht, sucht das in Hydrogen, Spartacus oder FastStore vergeblich.
Selten DACH-Compliance out of the box
Die meisten der genannten Plattformen kommen aus den USA oder werden global vertrieben. EU-Hosting in Frankfurt, AVV-Standard, WCAG 3.0 Ready und deutscher Support sind die Ausnahme. Für Brands in regulierten Branchen (Finanzdienstleister, öffentlicher Sektor, DORA-betroffene Unternehmen) reicht das oft nicht. Die Compliance-Lücke wird dann mit Custom-Setups geschlossen, was die TCO weiter nach oben treibt.
Multi-Brand und Multi-Market sind Custom
Native Frontends sind in der Regel auf einen Storefront pro Setup ausgelegt. Brands mit zehn Marken oder zehn Märkten betreiben zehn Storefronts, mit zehn Code-Bases, zehn Deployments, zehn Wartungssträngen. Eine zentrale Plattform-Sicht, in der eine Marketing-Person alle Marken pflegt, ist im nativen Frontend-Modell nicht vorgesehen.
Wann ein natives Frontend reicht und wann nicht
Native Frontends sind nicht per se die falsche Wahl. Es gibt Setups, in denen sie genau richtig sind:
Eine Brand, ein Backend, ein etabliertes Engineering-Team, dessen Hauptberuf der Storefront-Bau ist.
Sehr individuelle Storefronts mit einzigartiger Render-Logik, die in keiner Plattform abbildbar wäre.
Setups, in denen das Engineering-Team aktiv den Wettbewerbsvorteil im Frontend bauen will und die Plattform bewusst nah am Backend halten will.
Sobald aber einer der folgenden Punkte zutrifft, kippt die Rechnung:
Multi-Brand- oder Multi-Market-Strategie mit mehreren Backends.
Marketing-Teams, die selbstständig Landingpages, Kampagnen und Promo-Aktionen veröffentlichen sollen.
Time-to-Market-Anspruch von Wochen statt Monaten.
KI-getriebene Storefront-Operations als strategischer Hebel.
Strikte EU-Compliance, DSGVO, AVV, WCAG 3.0 und DACH-spezifischer Support.
In diesen Fällen lohnt der Schritt zu einer agentic Frontend-Management-Plattform.
Die Kategorie, die diese Lücke schließt: Agentic Frontend Management
Eine agentic Frontend-Management-Plattform ist eine Plattform-Schicht oberhalb eures Commerce-Backends, die das gesamte Storefront-Rendering, das visuelle Page-Building, die UI-Komponenten und die KI-Operations in einer Plattform bündelt. Anders als Hydrogen oder Spartacus ist sie backend-agnostisch und bringt einen visuellen Studio mit, in dem Marketing- und Content-Teams ohne Dev-Ticket arbeiten.
Genau in dieser Kategorie positionieren wir uns mit Laioutr. Wir verbinden uns nativ mit über neunzehn Commerce-Backends, darunter Shopify, Shopware, commercetools, Adobe Commerce, SAP Commerce Cloud, VTEX, BigCommerce und Salesforce Commerce Cloud. Storefronts laufen auf Themes und einer vollständigen UI-Library. Marketing-Teams ziehen Landingpages und Produktwelten direkt im Laioutr Studio. Larry, unser KI-Agent, übernimmt Storefront-Operations, von Layout-Vorschlägen bis Konversions-Optimierung. EU-Hosting in Frankfurt, AVV-Standard, WCAG 3.0 Ready und deutscher Founder-Support sind im Plattform-Standard enthalten.
Wer sich genauer ansehen will, wie das in eurem Stack funktioniert, findet die Übersicht hier: Agentic Frontend Management Platform.
Die nächste Stufe: Composable Digital Experience Platform
Frontend allein ist heute nicht mehr genug. E-Commerce-Brands brauchen eine Plattform, die Storefront, Content, Commerce, Personalisierung und KI in einem System orchestriert. Eine Composable Digital Experience Platform (Composable DXP) ist die Antwort auf das, was monolithische DXPs (Adobe Experience Manager, Sitecore, Acquia) in der modernen Composable-Architektur leisten müssen, ohne ihre Schwerfälligkeit.
Die Composable DXP von Laioutr kombiniert die agentic Frontend-Management-Schicht mit nativen Anbindungen zu Headless CMS (Storyblok, Contentful, Hygraph), zu Commerce-Backends, zu Personalisierungs-Tools und zu KI-Workflows. Brands bekommen damit eine Plattform, die mit ihrer Composable-Strategie wachsen kann, statt einen monolithischen DXP-Käfig zu zementieren.
Mehr dazu, wie Composable DXP funktioniert und welche Rolle Laioutr darin spielt, im Detail hier: Composable Digital Experience Platform.
Fazit: Native Frontends sind ein Werkzeug, keine Plattform
Hydrogen, Spartacus, FastStore, Catalyst, commercetools Frontend, PWA Studio, Shopware Frontends und die anderen nativen Frontend-Lösungen der großen Shop-Systeme sind ausgereifte Werkzeuge. Für Brands mit der passenden Setup-Größe, einem starken Engineering-Team und einem klaren Ein-Backend-Setup funktionieren sie. Sobald aber Multi-Brand, Multi-Backend, Marketing-Self-Service, Time-to-Market in Wochen, KI-First oder DACH-Compliance ins Spiel kommen, reichen sie nicht mehr.
DACH-E-Commerce-Brands, die sich heute strategisch positionieren, wählen zunehmend eine agentic Frontend-Management-Plattform statt einer nativen Frontend-Lösung. Die Plattform-Logik bringt Composable Commerce in eine Form, die für Marketing, Engineering und Compliance gleichzeitig funktioniert.
Übersicht aller nativen Shop-System-Frontends im Schnellblick
Enterprise und Mid-Market global: Shopify (Hydrogen, Liquid), BigCommerce (Catalyst, Stencil), Adobe Commerce (PWA Studio, Edge Delivery, Luma), Salesforce Commerce Cloud (Composable Storefront, SFRA), SAP Commerce Cloud (Spartacus), commercetools (commercetools Frontend), Shopware (Shopware Frontends, Default Storefront), VTEX (FastStore, VTEX IO), Spryker (Composable Frontend, Yves), Elastic Path (Studio), WooCommerce (Storefront-Theme), Centra, Intershop, OroCommerce, Kibo Commerce.
Open Source und Modern Headless: Saleor (Saleor Storefront), Medusa (Medusa Next.js Starter), Vendure (Storefront-Starter), Sylius (Symfony Twig), PrestaShop, OpenCart, nopCommerce.
SaaS und SMB: Wix Commerce, Squarespace Commerce, Ecwid, Big Cartel, Volusion, Lightspeed eCom, JTL-Shop, xt:Commerce, Gambio.
Asien-Schwerpunkt: Tmall, JD.com, Rakuten Ichiba, Cafe24, NHN Commerce.
Alle Daten basieren auf öffentlich verfügbaren Informationen, Erfahrungen aus Sales-Gesprächen mit DACH-E-Commerce-Brands sowie eigenen Plattform-Tests. Stand: April 2026. Funktionsumfänge der genannten Shop-System-Frontends entwickeln sich laufend weiter, prüft im Zweifel die Hersteller-Dokumentation auf den aktuellen Stand.