Ein Gespräch über einen neuen Shop beginnt fast immer gleich. Der Kunde hat drei Tabs mit Preislisten offen und fragt, welche Plattform günstiger ist. Nur fragt er eigentlich etwas ganz anderes: ob sich seine Art zu verkaufen in diesem Werkzeug abbilden lässt, ohne alles mit Klebeband und manuellen Exporten in eine Tabelle zusammenzuhalten.
Die Preisliste zieht die Aufmerksamkeit auf sich, weil sie das Einzige ist, was man vor dem Start sieht. Der Rest zeigt sich später: bei der ersten Anbindung an die Buchhaltung, in der ersten Rabattsaison, bei der ersten Retoure, die sich nach der Firmenprozedur nicht abwickeln lässt.
Deshalb behandeln wir die Wahl der E-Commerce-Plattform als Entscheidung über Prozesse, nicht über ein Abonnement. Bestellung, Lager, Abrechnung, Reklamationsbearbeitung: Sie stecken die Grenzen dessen ab, was sich sinnvoll bauen lässt. Ein B2C-Shop mit einem Lager und ein Großhandel mit individuellen Preisen für jeden Geschäftspartner stellen dieselbe Frage, und sie sollten zwei verschiedene Antworten hören.
Inhaltsverzeichnis
Beginnen Sie mit einer Prozesslandkarte, nicht mit einer Funktionsliste
Die Frage “hat die Plattform Funktion X” führt nirgendwohin. Jede wird sie bejahen, nur auf einem anderen Detailgrad. Besser ist es, den Weg einer Bestellung vom Klick bis zur Rechnung und einer möglichen Retoure zu beschreiben und dabei jeden Punkt zu markieren, an dem ein Mensch oder ein anderes System eingreift.
Nach unserer Erfahrung entscheiden einige wenige Bereiche über die Wahl:
- Preismodell und Rabattierung – Preise erst nach dem Login sichtbar, Mengenstaffeln, individuelle Handelskonditionen.
- Varianten und Konfiguratoren – aus Optionen zusammengesetzte Produkte, Preisbildung abhängig von Parametern.
- Lagerbestände und Reservierungen – mehrere Lager, Sperrung der Ware für die Dauer der Zahlung, Nachbestellungen.
- Verkaufsbelege und steuerliche Konformität – Rechnungen, Korrekturen, Sätze für verschiedene Länder.
- Logistik und Retouren – Versandetiketten, Abholpunkte, Ablauf der Reklamation.
- Mehrere Märkte und Sprachen – getrennte Kataloge, Währungen, Inhalte.
- Berechtigungen im Team – wer sieht Margen, wer darf einen Preis ändern.
Der häufigste Fehler? Eine Entscheidung, die in der Demo fällt. Dort sieht alles ähnlich aus, denn jede Lösung kann ein Produkt in den Warenkorb legen. Das echte Warnsignal ist ein anderes: Wenn ein Prozess heute in einer Tabelle und im Mailpostfach lebt, wird ihn keine Plattform von allein reparieren. Zuerst muss er beschrieben werden.
Wo die Konfiguration endet und der Code beginnt
Jede der drei Lösungen zieht diese Grenze woanders. Shopify schließt das Backend ab und verlagert ungewöhnliche Logik in Apps und Funktionen, die in der Cloud des Anbieters laufen. Deshalb planen wir Shop-Umsetzungen auf der Shopify-Plattform anders als die übrigen. WooCommerce und PrestaShop geben den Zugriff auf die Serverschicht frei, sodass eine Verhaltensänderung des Shops oft eine Frage eines einzigen Hooks im Code ist.
Die Folge ist architektonisch, nicht ästhetisch. Im geschlossenen Modell zahlen Sie mit Flexibilität: Manches lässt sich schlicht nicht umsetzen, und Umwege müssen in fremde Limits passen. Im offenen zahlen Sie mit Verantwortung: für Updates, für Sicherheit, dafür, dass der Warenkorb nach dem Einspielen eines Patches weiterhin funktioniert.
Nehmen wir ungewöhnliche Preise für einen eingeloggten Geschäftspartner. In der einen Welt ist das ein Plugin und ein paar Zeilen im Code, der den Preis berechnet. In der anderen eine eigene App, weitere API-Aufrufe und die Frage, ob sie antwortet, bevor die Seite gerendert wird. Aber Achtung: Das geschlossene Modell kann für ein kleines Team ohne IT-Abteilung ein echter Vorteil sein, wenn es nicht nach einem nächtlichen Update mit einem defekten Shop aufwachen möchte.
Integrationen entscheiden häufiger als der Shop selbst
Ein Shop steht selten allein. Daneben arbeiten ein ERP, ein Lager, ein Rechnungssystem, Zahlungs-Gateways, Versanddienstleister, manchmal ein CRM und Marketingwerkzeuge. Und genau diese Verbindungen, nicht das Grafik-Template, erzeugen den größten Teil des Projektrisikos.
Die Frage, die wir vor der Wahl stellen, lautet so: Soll der Datenaustausch synchron oder über eine Warteschlange laufen, und was passiert, wenn die Gegenseite schweigt. “Wir versuchen es noch einmal” reicht nicht, wenn ein Kunde in der Zwischenzeit Ware gekauft hat, die es nicht mehr gibt.
API-Limits und Einschränkungen bei Webhooks in Cloud-Plattformen können eine Massensynchronisation der Bestände umwerfen, die im Angebot niemand durchgerechnet hat. Ein Katalog, der viertelstündlich aus dem Lagersystem aktualisiert wird, sieht harmlos aus. Bis zum Aufprall auf ein hartes Anfragenbudget. Auf der offenen Seite treffen wir am häufigsten auf Online-Shops auf Basis von PrestaShop, die an ein ERP angebunden sind und bei denen sich die Warteschlange nach eigenem Bedarf einstellen lässt.
Der zweite Klassiker ist ein fertiger ERP-Konnektor, gekauft ohne die Prüfung, ob er alle von der Buchhaltung genutzten Felder abbildet. Meist endet es mit einer Zwischenschicht, die ohnehin geschrieben werden muss. Nur eben später und unter Druck.
Kostenstruktur: was die Rechnung wirklich treibt
Die Rechnung für einen Shop setzt sich zusammen aus Lizenz oder Abonnement, Transaktionsprovisionen, Plugins und Apps, Hosting, Umsetzung, Integrationen und laufender Wartung. Die Preisliste zeigt den ersten dieser Posten und schweigt über den Rest. Damit ein Budgetgespräch einen Anknüpfungspunkt hat, veröffentlichen wir Richtpreise für Umsetzungen.
Das Cloud-Modell verteilt die Kosten über die Zeit und koppelt sie an den Umsatz: Je mehr Sie verkaufen, desto mehr zahlen Sie, dafür kümmern Sie sich nicht um den Server. Self-hosted verschiebt die Ausgabe an den Anfang und auf das Team, das danach aktualisiert, testet und die Sicherheit im Auge behält.
Offene Plattformen haben versteckte Kosten in den Abhängigkeiten. Jedes Plugin ist fremder Code, der nicht mehr weiterentwickelt werden kann und dann Updates des gesamten Shops blockiert, Sicherheitspatches inklusive. Geschlossene haben ihre eigenen: Eine fehlende Funktion zu umgehen ist mitunter teurer, als sie direkt zu schreiben, weil sie in Grenzen gepresst werden muss, auf die Sie keinen Einfluss haben.
Skalierung, Sicherheit und Daten, also das Leben nach dem Start
Skalierung im Onlinehandel betrifft selten den Traffic auf der Seite. Fast immer geht es um die Datenbank. Ein Katalog mit vielen Varianten, eine wachsende Bestellhistorie, Abfragen mit Filtern über Attribute: Das kann einen Shop verlangsamen, der zum Start einwandfrei lief.
Die Verantwortung für die Sicherheit verteilt sich in beiden Modellen völlig unterschiedlich. In der Cloud aktualisiert der Anbieter, und es ist sein Problem. In der selbst installierten Variante tut es eine konkrete Person im Team oder, was wir am häufigsten sehen, niemand. Bis zum Vorfall.
Kunden- und Bestelldaten sind ein Vermögenswert, kein Nebeneffekt. Sie müssen sich in roher Form exportieren lassen, sonst stützt sich die Analytik auf die Diagramme des Anbieters, und eine künftige Migration wird zum archäologischen Projekt. Die Wartung plant man vor dem Start: wer aktualisiert, wo das Backup liegt, wie die Testumgebung aussieht und wie eine Änderung ausgerollt wird.
Wie eine gute Entscheidung in der Praxis aussieht
Eine gute Entscheidung ist umkehrbar. Sie geht davon aus, dass sich die Bedingungen in zwei Jahren ändern können, also plant man Integrationen mit Blick auf einen Austausch und hält die Daten so, dass sie sich verschieben lassen, ohne das halbe Unternehmen neu zu schreiben.
Die Profile ordnen sich recht klar. Ein einfacher Katalog und ein schneller Start: das Cloud-Modell. Ein Shop, der eng mit Inhalten und einem bestehenden WordPress verwachsen ist, tendiert natürlicherweise zu einer Lösung wie einem Online-Shop auf Basis von WooCommerce. Ein umfangreicher Verkauf mit eigener Geschäftslogik und vielen Märkten verlangt volle Kontrolle über den Code.
Vor der Vertragsunterzeichnung empfehle ich eine einfache Probe: Beschreiben Sie die drei schwierigsten Szenarien Ihres Prozesses und bitten Sie den Dienstleister zu zeigen, wie er sie in der vorgeschlagenen Lösung umsetzt. Eine gelungene Einführung beginnt beim Prozess und endet bei der Plattform. Eine misslungene läuft genau andersherum.
Zusammenfassung
Eine Plattform ist ein Werkzeug zur Abwicklung des Verkaufsprozesses, also gibt es nur eine Reihenfolge: zuerst den Prozess beschreiben, dann die Werkzeuge vergleichen. Die Preisliste ergibt dann einen Sinn, weil endlich klar ist, was genau Sie kaufen.
Nehmen Sie aus dem Treffen mit dem Dienstleister drei Kontrollfragen mit. Wo endet die Konfiguration und wo beginnt die Programmierung. Wie verhalten sich die Integrationen unter Last und bei einem Ausfall der Gegenseite. Wer betreut diesen Shop in einem Jahr. Die Antworten sagen mehr über das Projekt als eine Funktionsliste.
Bei Web Systems entwerfen wir seit 2006 Webanwendungen, B2B-Systeme und Integrationen, deshalb sehen wir einen Shop als Teil eines größeren Puzzles. Wenn Sie vor der Wahl einer Plattform stehen, die Verbindung des Verkaufs mit einem ERP planen, eine Migration, eine Prozessautomatisierung oder die Modernisierung eines laufenden Shops, melden Sie sich – wir beginnen bei Ihrem Prozess, nicht bei einer fertigen Empfehlung.
