Wofür wir Shopware einsetzen
Der typische Fall ist ein Großhändler oder Hersteller, der seinen Bestandskunden einen Bestellkanal geben will. Preise sind dort selten öffentlich: Jeder Kunde sieht seine Konditionen, oft mit Staffeln und Sonderpreisen auf Artikelebene. Dazu kommen Organisationsstrukturen — eine Zentrale, mehrere Niederlassungen, Besteller mit Budget und Einkäufer mit Freigaberecht. Wer B2B behandelt wie D2C mit vorgeschaltetem Login, baut einen hübschen Katalog, den niemand benutzt.
Der zweite häufige Fall ist die Anbindung an die Beschaffung des Kunden. Große Einkäufer bestellen nicht im Browser, sondern aus ihrem SAP-, Onventis- oder Coupa-System heraus. Dafür implementieren wir OCI-Punch-out und cXML: Der Warenkorb entsteht im Shop und wandert zurück ins Beschaffungssystem, wo die interne Freigabe läuft. Daneben laufen klassische D2C-Projekte über Shopware 6, meist dann, wenn Sortiment, Varianten oder Zahlarten über das hinausgehen, was ein WooCommerce-Setup sinnvoll trägt.
Wie wir mit Shopware 6 arbeiten
Shopware 6 ist eine Symfony-Anwendung. Alles, was ein Projekt an Eigenheiten mitbringt, entsteht bei uns als eigenes Plugin oder App — mit eigenen Entities, Services und Twig-Erweiterungen über den Theme-Layer. Am Core wird nichts geändert. Das klingt selbstverständlich, ist es aber nicht: Core-Hacks sind der häufigste Grund, warum ein Shop mehrere Versionssprünge hinterherhängt und niemand das Update anfassen will.
Preislogik bilden wir über den Rule Builder ab, solange sie sich mit Bordmitteln beschreiben lässt; wird es komplexer, kommt eine eigene Price-Rule-Implementierung dazu. Für Suche und Last setzen wir Elasticsearch und Redis ein, wo Datenmenge und Traffic es rechtfertigen — nicht als Standardausstattung. Headless-Anforderungen laufen über die Store-API. Deployment, Staging und Updates gehören zum Projekt, nicht zum Sonderwunsch: Ein Shop, der nur zum Launch aktuell ist, ist ein Sicherheitsproblem mit Zeitverzögerung.
Grenzen: wann Shopware die falsche Wahl ist
Shopware 6 ist kein leichtes System. Für einen Shop mit einer Handvoll Artikel, einem Preis pro Artikel und ohne Warenwirtschaftsanbindung ist der Stack überdimensioniert — dort raten wir zu WooCommerce, besonders wenn ohnehin schon WordPress läuft. Auch bei reinen Content-Auftritten mit angehängtem Verkauf weniger Produkte lohnt der Betriebsaufwand selten. Betriebsaufwand heißt hier: Updates, Testumgebung, Monitoring, Plugin-Pflege, Zertifikate.
Die zweite Grenze verläuft beim Marktplatz. Wer Fremdanbieter, Provisionsabrechnung und getrennte Auszahlungen braucht, arbeitet gegen das Datenmodell an; da ist eine Plattform mit Multi-Vendor-Kern der ehrlichere Weg. Und wenn ein Shopware-5-Shop noch läuft: Shopware 5 ist seit Ende Juli 2024 eingestellt, Sicherheitsupdates gibt es nur noch kommerziell über einen Drittanbieter. Ein Upgrade ist technisch ein Neubau mit Datenübernahme, kein Versionssprung. Wir sagen das vorher, weil die Kalkulation sonst im Projekt kippt.