Saleor für Einzelhändler: ein Storefront ohne GraphQL-Eigenbau

Saleor hat sich zu einer ernstzunehmenden Option für Enterprise- und Midmarket-Einzelhändler entwickelt, die ein Commerce-Backend suchen, das weder Shopify Plus noch SAP Commerce Cloud ist. Es ist Open Source, GraphQL-nativ, EU-hostbar und ohne Umsatzbeteiligung pro Transaktion. Der Punkt, der in fast jedem Saleor-Evaluierungsgespräch auftaucht: Saleor liefert eine API, keinen Storefront. Der Weg von „wir haben uns für Saleor entschieden" zu „wir haben einen laufenden Shop" bedeutet, dass jemand in Ihrem Team einen GraphQL-Frontend von Grund auf baut, und dieser Bau ist ein größeres Projekt, als die meisten Einzelhändler am ersten Tag einplanen.

Warum Einzelhändler Saleor überhaupt in Betracht ziehen

Saleors Reiz für Einzelhändler ist konkret, nicht werblich. Es ist Open Source, also entsteht keine Lizenzgebühr, die an Ihren GMV gekoppelt ist. Es läuft auf GraphQL, was Engineering-Teams eine einzige typisierte Abfrageebene gibt, statt mehrere REST-Endpunkte zusammenzustückeln. Es unterstützt Multi-Channel- und Multi-Currency-Kataloge nativ, was für Einzelhändler zählt, die mehrere Märkte aus einem Backend bedienen. Und weil es selbst gehostet oder in der EU gehostet werden kann, entfallen die Datenresidenz-Fragen, die bei US-gehosteten SaaS-Plattformen aufkommen.

An dem, was nach der Backend-Entscheidung passiert, ändert das nichts. Saleor ist Commerce-Logik: Katalog, Warenkorb, Checkout-Orchestrierung, Auftragsverwaltung, Zahlungsanbindungspunkte. Die Präsentationsebene, der eigentliche Storefront, in dem Ihre Kunden stöbern und kaufen, ist ein separater Bau. Einzelhändler, die Saleor am ehesten auf die Shortlist setzen, betreiben bereits einen composable- oder MACH-orientierten Stack oder verlassen einen monolithischen Plattform-Vertrag, der nicht mehr zur Multi-Market-Roadmap passt, und in beiden Gruppen ist der Frontend-Bau der Projektteil, der zuerst unterschätzt wird.

Die GraphQL-Frontend-Realität

Sobald Saleor Ihr Backend ist, liegt es an Ihrem Team, einen funktionierenden Satz von GraphQL-Queries und -Mutations zu bauen, der Produktlisten-Seiten, Produktdetailseiten, facettierte Suche, Warenkorb-Zustand und einen vollständigen Checkout-Flow rendert. Dazu gehört die Anbindung von Zahlungsanbietern (Stripe, Adyen und Mollie sind im Saleor-Ökosystem gängige Wahl), die Handhabung von Multi-Locale-Content und Währungsumschaltung, das Erreichen akzeptabler Core-Web-Vitals-Werte und die Erzeugung strukturierter Daten, die Suchmaschinen und KI-Shopping-Agenten erwarten. Nichts davon ist exotisches Engineering, aber alles davon ist echtes Engineering, und all das liegt vollständig außerhalb von Saleors eigenem Umfang.

Einzelhändler, die diesen Schritt unterschätzen, entdecken das meist während eines Anbietervergleichs: Die Backend-Entscheidung hat wenige Wochen gedauert, der Frontend-Bau dauert mehrere Monate.

Eigenbau-GraphQL-Frontend vs. gemanagter Saleor-Frontend

• Benötigtes Team. Eigenbau-GraphQL-Frontend: Dedizierte Frontend-Engineers, dauerhaft. Gemanagter Saleor-Frontend (FMP): Bestehendes Marketing-/Ops-Team, leichte Dev-Unterstützung.
• Zeit bis zum ersten Live-Storefront. Eigenbau-GraphQL-Frontend: Typisch 4-6 Monate für vollständigen Katalog und Checkout. Gemanagter Saleor-Frontend (FMP): Wochen, Backend bleibt unangetastet.
• Checkout- und Zahlungsanbindung. Eigenbau-GraphQL-Frontend: Intern gebaut und gepflegt. Gemanagter Saleor-Frontend (FMP): Vorintegriert, auf Ihren Anbieter konfiguriert.
• Core Web Vitals und SEO. Eigenbau-GraphQL-Frontend: Liegt bei Ihrem Engineering-Team. Gemanagter Saleor-Frontend (FMP): Als Teil der Plattform verwaltet.
• Laufende Wartung. Eigenbau-GraphQL-Frontend: Ihr Team verfolgt jede Saleor-API-Änderung. Gemanagter Saleor-Frontend (FMP): Wartung und Upgrades übernimmt die Plattform.
• Agent-Readiness (Schema.org, strukturierte Produktdaten). Eigenbau-GraphQL-Frontend: Erfordert dedizierte Umsetzung. Gemanagter Saleor-Frontend (FMP): Von Anfang an eingebaut.

Was ein gemanagter Frontend operativ verändert

Einzelhändler, die den Frontend vom Saleor-Backend über eine Frontend Management Platform entkoppeln, ersetzen Saleor nicht, sie verändern, wer den Bau- und Release-Zyklus des Storefronts verantwortet. Saleor macht weiterhin das, was es gut kann: Katalog, Checkout-Orchestrierung, Auftragsdaten. Der Frontend wird zu einer unabhängig deploybaren, unabhängig upgradebaren Ebene, die Ihr Marketing-Team im Tagesgeschäft betreiben kann, ohne für jede neue Kampagnen-Seite oder saisonale Kollektion ein Developer-Ticket aufzumachen.

Hier zählt auch das Betriebsmodell Frontend as a Service mehr als jede einzelne Feature-Liste: Der Frontend ist kein Projekt, das Sie einmal abschließen, sondern eine gemanagte Betriebsebene, die aktuell bleibt, während sich Saleors API weiterentwickelt, ohne dass Ihr Team das Upgrade-Risiko direkt trägt. Für Einzelhändler, die bereits einen Saleor-Piloten betreiben oder Headless-Frontend-Optionen für Saleor prüfen, ist genau dieser Unterschied, Projekt versus Betriebsebene, meist der entscheidende Faktor.

Was das für Händler bedeutet

• Wenn Sie sich bereits für Saleor als Backend entschieden haben, planen Sie den Frontend-Bau als separates, vergleichbar großes Projekt, nicht als Fußnote.
• Wenn Ihr Team nicht dauerhaft über dedizierte Frontend-Engineers verfügt, nimmt Ihnen ein gemanagter Frontend die laufende Wartungslast ab, die ein Eigenbau-GraphQL-Frontend erzeugt.
• Wenn Launch-Geschwindigkeit für neue Märkte oder Kampagnen wichtiger ist als jede Zeile Frontend-Code selbst zu besitzen, bringt Sie ein gemanagter Storefront in Wochen statt Monaten live.
• Wenn Agent-Readiness (strukturierte Produktdaten für KI-Shopping-Agenten) auf Ihrer Roadmap für 2026/2027 steht, bauen Sie sie von Anfang an ein, statt sie später nachzurüsten.
• Wenn Sie Saleor gegen Shopify Plus oder SAP Commerce Cloud abwägen, rechnen Sie die Frontend-Baukosten in den Gesamtvergleich ein, nicht nur die Backend-Lizenzbedingungen.

FAQ

Bringt Saleor einen Storefront von Haus aus mit? Saleor liefert eine GraphQL-Commerce-API. Ein produktionsreifer Storefront, die Seiten, auf denen Kunden tatsächlich stöbern und bezahlen, ist ein separater Bau, ob Eigenbau oder gemanagt.

Wie lange dauert es, einen Saleor-basierten Storefront zu launchen? Ein vollständiger Eigenbau-GraphQL-Frontend läuft typischerweise 4-6 Monate für Katalog und Checkout. Ein gemanagter Frontend, der sich an Saleors API anbindet, kann in Wochen live gehen, weil die Präsentationsebene bereits gebaut und konfiguriert ist.

Brauchen wir ein großes Engineering-Team, um Saleor zu betreiben? Um einen Eigenbau-Frontend zu pflegen, ja, dauerhaft. Um einen gemanagten Frontend über Saleor zu betreiben, kann Ihr bestehendes Marketing- oder Ops-Team Tagesgeschäft-Änderungen übernehmen, mit leichter Developer-Unterstützung für Backend-Anbindungen.

Können wir den Frontend-Ansatz später wechseln, ohne Saleor anzufassen? Ja. Weil Frontend und Saleor-Backend über die GraphQL-API kommunizieren, können Sie Ihre Präsentationsebene wechseln, vom Eigenbau zur gemanagten Plattform oder umgekehrt, ohne Ihre Commerce-Daten zu migrieren.

Wie sieht der realistische Engineering-Aufwand für einen Eigenbau-Saleor-Frontend aus? Planen Sie ein kleines dediziertes Frontend-Team ein (typisch zwei bis vier Engineers) für den initialen Bau über 4-6 Monate, plus laufende Kapazität danach für Zahlungsanbieter-Updates, Saleor-API-Versionswechsel und Core-Web-Vitals-Pflege. Genau diese laufende Kapazität, nicht der initiale Bau, ist das, was die meisten Einzelhändler unterschätzen, wenn sie einen Eigenbau-GraphQL-Frontend gegen Saleor kalkulieren.