Open Source oder Closed Source: Wie KI die Wahl zwischen WooCommerce und Shopify verändert

Wer einen Onlineshop aufbaut oder wechselt, landet schnell bei Shopify. Die Marke ist bekannt, die Plattform gilt als sichere Wahl und für viele steht die Entscheidung damit fest, bevor sie getroffen wurde. Die Alternative heisst WooCommerce und wird meist auf ein Gegensatzpaar verkürzt: Open Source gegen Closed Source. In der Praxis hängt die Wahl an Wartungsaufwand, Datenhoheit und daran, wie stark sich das eigene Geschäft verändern wird.

Seit 2026 kommt ein Kriterium dazu: Wie gut lässt sich eine Plattform von KI-Werkzeugen erschliessen? Im Webinar «Ecommerce today: Open Source vs Closed Source» vom 26. August 2026 diskutierten das Shani Banerjee, Brian Coords und Shubert Koong von WooCommerce sowie Ian Misner, Mitgründer des Extension-Anbieters Kestrel. Die Veranstaltung richtete sich an Agenturen. Wir prüfen die Argumente nach und ordnen sie aus Händlersicht ein.

Inhalt

Wann Shopify die bessere Wahl ist

Die erste Frage des Panels war für ein Hersteller-Webinar bemerkenswert direkt: Wann sollte eine Agentur Shopify oder Wix empfehlen, obwohl sie technisch problemlos einen WooCommerce-Shop bauen könnte? Die Antwort fiel differenzierter aus als erwartet. Shopify wurde nicht schlechtgeredet, im Gegenteil.

Entscheidend sei, wie ein Betrieb arbeitet. Wie viel willst du selbst administrieren? Wie komplex sind deine Prozesse? Welche Anforderungen bestehen an Checkout, Produkte und B2B-Funktionen? Bei überschaubaren Anforderungen hat eine weitgehend vorkonfigurierte Plattform Vorteile: Das Backend ist standardisiert, viele Funktionen sind eingebaut und es gibt weniger, das schiefgehen kann.

WooCommerce wird interessanter, sobald Anforderungen über den Standard hinausgehen. Typische Fälle sind individuelle Checkout-Prozesse, Kombinationen aus B2C und B2B, Wholesale-Funktionen, spezielle Preislogiken, individuelle Produktmodelle, Integrationen in ERP-, CRM- oder Logistiksysteme sowie besondere Anforderungen an Hosting und Datenhaltung. Bei WooCommerce lautet die Antwort auf solche Wünsche fast immer: technisch machbar. Die schwierigere Frage lautet, ob es sinnvoll ist.

Die Plattformwahl ist eine Wette auf künftige Anforderungen

Ian Misner formulierte einen Entscheidungsfaktor, der über das Lastenheft hinausgeht. Die Frage sei nicht nur, was ein Shop heute können muss, sondern wie wahrscheinlich es ist, dass in sechs Monaten die nächste ungewöhnliche Anforderung dazukommt.

Das klingt selbstverständlich, hat aber konkrete Folgen. Ein Shop mit 30 Produkten, zwei Zahlungsarten und Standard-Checkout funktioniert auf beiden Plattformen. Einige Jahre später kommen vielleicht internationale Märkte dazu, B2B-Kundinnen und -Kunden, individuelle Preislisten, mehrere Warenlager, Abonnements oder externe Marktplätze. Dann zeigt sich, wie leicht sich die ursprüngliche Wahl erweitern lässt.

Eine Plattformentscheidung ist deshalb selten nur eine technische Entscheidung über den heutigen Shop. Sie ist teilweise eine Wette auf Anforderungen, die noch niemand kennt. Wie sich Anforderungen an Shops verschieben, haben wir in Der Shop allein reicht nicht mehr beschrieben.

Datenhoheit: Ideal oder wirtschaftlicher Vorteil?

Open Source wird gerne mit Freiheit und Datenhoheit beworben. Für Shop Betreiberinnen und Betreiber sind solche Argumente aber nur überzeugend, wenn daraus ein konkreter Nutzen entsteht. Bei WooCommerce liegen Shop, Datenbank und Anwendung unter der Kontrolle des Betreibers. Das verändert vor allem die Abhängigkeit vom Plattformanbieter.

Bei proprietären Plattformen bestimmt der Anbieter, welche Produktkategorien erlaubt sind, welche Zahlungsanbieter eingebunden werden können, welche APIs verfügbar sind und welche Limits gelten, wo Daten verarbeitet werden und unter welchen Umständen ein Shop gesperrt werden kann. In den meisten Projekten führt das zu keinen Problemen. Die Schwierigkeit besteht darin, dass man Plattformabhängigkeit erst bemerkt, wenn eine Einschränkung auftritt. Eine geänderte Nutzungsbedingung, ein regulatorisches Problem oder eine gesperrte Produktkategorie kann dann geschäftskritisch werden.

Ehrlicherweise gilt: Auch ein WooCommerce-Shop lässt sich lahmlegen, im ungünstigsten Fall genügt ein fehlerhaftes Plugin. Der Unterschied liegt darin, dass man Zugriff auf den gesamten Stack hat und den Fehler selbst beheben kann.

Warum KI offenen Quellcode wertvoller macht

Hier liegt das stärkste Argument des Panels. Ein vollständiger WooCommerce-Shop lässt sich lokal replizieren. Entwicklerinnen und Entwickler können auf Quellcode, Datenstrukturen, Plugins und Konfiguration zugreifen und einem Coding Agent diese Umgebung als Kontext geben. Der Agent kann dann untersuchen, wie ein Plugin Daten speichert, welche Hooks zur Verfügung stehen, wie sich der Checkout anpassen lässt und warum eine Funktion nicht wie erwartet arbeitet. Bei einer geschlossenen Plattform endet diese Analyse dort, wo der Anbieter die Grenze setzt.

Früher bedeutete Quellcodezugriff vor allem, dass eine Entwicklerin theoretisch jede Zeile lesen konnte. Praktisch tat das niemand, weil die Zeit fehlte. Ein Coding Agent durchsucht Millionen Zeilen in Minuten, stellt Zusammenhänge her und leitet daraus Implementierungen ab. Der Wert von offenem Quellcode steigt also gerade deshalb, weil Menschen ihn nicht mehr vollständig selbst lesen müssen.

WordPress hat dabei einen zusätzlichen Vorteil: Core, WooCommerce, zahlreiche Plugins und ein grosser Teil der Dokumentation sind öffentlich. Sprachmodelle kennen das Ökosystem entsprechend gut. Dazu kommen Hooks, Filter, REST-Schnittstellen und WP-CLI, die seit Jahren definierte Erweiterungspunkte bieten. Ein Agent muss bestehende Plugins nicht verändern. Er kann analysieren, welche Hooks existieren, um darauf ein eigenes Plugin aufzusetzen. Warum bei WordPress weniger die Technik als das Vertrauen ins Ökosystem den Ausschlag gibt, haben wir in WordPress im KI-Zeitalter eingeordnet.

Die Werkzeuge: MCP-Server, Studio und QIT

Drei Bausteine machen diesen Ansatz praktisch nutzbar. Alle drei sind neuer, als die Diskussion vermuten lässt.

Der WooCommerce MCP Server: Seit WooCommerce 10.9 vom 23. Juni 2026 ist ein Server für das Model Context Protocol direkt eingebaut, aufbauend auf der Abilities API, die seit WordPress 6.9 im Core steckt. Er stellt sieben Fähigkeiten bereit, darunter Produkte abfragen, erstellen, aktualisieren und löschen sowie Bestellungen abfragen und deren Status ändern. Die Authentifizierung läuft über Application Passwords. Wichtig für die Einschätzung: WooCommerce bezeichnet das ausdrücklich als Developer Preview und weist darauf hin, dass sich Bezeichner und Datenformate noch ändern können.

WordPress Studio: Die kostenlose Desktop-Anwendung von Automattic erzeugt lokale WordPress-Installationen ohne Apache, NGINX oder MySQL, weil sie auf WordPress Playground und PHP via WebAssembly aufsetzt. Sie bringt einen Assistenten mit, der Installationen konfiguriert und WP-CLI-Befehle ausführt, begrenzt auf 200 Anfragen pro Monat und Nutzerkonto.

Das Quality Insights Toolkit: QIT testet Plugins und Themes automatisiert gegen konfigurierbare PHP-, WordPress- und WooCommerce-Versionen. Enthalten sind unter anderem End-to-End-Tests, API-Tests, Aktivierungs- und Sicherheitsprüfungen, PHPStan und eine Malware-Analyse. Eigene Playwright-Tests lassen sich ergänzen. Eine Einschränkung nennt die Dokumentation selbst: Die meisten Funktionen setzen ein Konto als Partner Developer des WooCommerce.com Marketplace voraus. Eine Öffnung ist angekündigt, aber noch nicht erfolgt. Nur die lokale Testumgebung läuft ohne Marketplace-Anbindung.

Die Demo: eine Black-Friday-Funktion per Coding Agent

Der praktisch interessanteste Teil war eine Demonstration mit einem bewusst alltäglichen Szenario. Ein Händler möchte für Black Friday eine Aktion durchführen: Sobald der Warenkorb einen bestimmten Wert erreicht, darf ein kostenloses Produkt hinzugefügt werden. Eine Agentur könnte dafür ein bestehendes Plugin suchen. Im Beispiel ging es um eine individuelle Lösung.

Der Entwickler arbeitete mit einer lokalen Kopie des Shops in WordPress Studio und einem Coding Agent, der Zugriff auf die Installation hatte. Über eine MCP-Verbindung konnte er zusätzlich lesend auf Daten des Live-Shops zugreifen. Der erste Auftrag lautete, die Umsätze der vergangenen Monate zu analysieren und Produkte zu identifizieren, die sich als Geschenk eignen. Der Agent holte die Daten und schlug Produkte anhand von Preis und Verkaufshistorie vor.

Das allein ist eine Verschiebung. Normalerweise müsste jemand WooCommerce öffnen, Berichte exportieren, Daten vergleichen und anschliessend mit dem Kunden diskutieren. Hier wird die Datenauswertung Teil des Entwicklungsprozesses.

Im nächsten Schritt sollte der Agent ein Plugin entwickeln, mit einem Block im Mini-Warenkorb, einer Fortschrittsanzeige und dem automatischen Freischalten ab einem bestimmten Betrag. Der Agent untersuchte selbstständig die Installation und musste dabei erkennen, ob der Shop die klassischen Shortcodes oder die neueren Cart- und Checkout-Blöcke verwendet, weil davon die verfügbaren Erweiterungspunkte abhängen. Danach erstellte er die Plugin-Dateien, führte WP-CLI-Befehle aus, aktivierte das Plugin und öffnete einen Browser, um selbst zu testen: Produkte in den Warenkorb legen, Mengen ändern, Anzeige prüfen.

Das Ergebnis war ein funktionierender Prototyp mit Fortschrittsbalken und freigeschaltetem Gratisprodukt. Design und Details waren nicht produktionsreif. Die erste vollständige Implementierung entstand aber, ohne dass jemand jede Codezeile selbst geschrieben hätte.

Nicht das Modell entscheidet, sondern der Harness

Zum Abschluss der Demonstration fiel die Formulierung, solche Anpassungen dauerten mit KI inzwischen Stunden statt Wochen. Das ist je nach Projekt optimistisch und stammt zudem von der Herstellerseite. Der wichtigere Punkt liegt woanders.

Der Agent schrieb nicht nur Code. Er analysierte Shopdaten, untersuchte Quellcode, traf Architekturentscheidungen, erzeugte Dateien, führte Kommandozeilenbefehle aus, testete im Browser, korrigierte Fehler und dokumentierte das Ergebnis. Damit verschiebt sich die Rolle der Entwicklerin: weniger einzelne Implementierungsschritte, mehr spezifizieren, kontrollieren und entscheiden.

Das deckt sich mit unserer eigenen Erfahrung. Der Fortschritt beim AI Coding entsteht nicht dadurch, dass ein Modell schönere einzelne Codezeilen erzeugt. Entscheidend ist der Harness, also die Arbeitsumgebung. Wenn ein Agent Zugriff auf Codebasis, Kommandozeile, Browser, Tests, Dokumentation und Projektdaten hat, kann er ganze Arbeitsabläufe übernehmen. Fehlt ihm einer dieser Zugänge, produziert er plausiblen Code, den niemand verifiziert hat.

Die Demonstration zeigte zugleich eine Grenze. Bevor der Agent über MCP ein Backup des Live-Shops anlegte, musste der Entwickler bestätigen. Auch erzeugter Code gehört vor dem Ausrollen geprüft. Im E-Commerce haben Fehler direkte finanzielle Folgen: Ein falscher Rabatt, ein fehlerhafter Checkout oder eine beschädigte Steuerberechnung ist etwas anderes als ein verrutschter Button auf einer Firmenwebsite.

Testen wird wichtiger als Programmieren

Passend dazu kam die Frage auf, ob WooCommerce eine Testsuite bereitstellen wird, die sich direkt mit Coding Agents verbinden lässt. Mit QIT existiert die Grundlage bereits, inklusive eines eigenen MCP-Servers, der die Kommandozeile des Toolkits für Agents zugänglich macht.

Die Richtung ist bemerkenswert. Je grösser der Anteil maschinell erzeugten Codes wird, desto stärker verschiebt sich der Engpass von der Produktion zur Verifikation. Die entscheidende Frage lautet dann nicht mehr, ob ein Modell eine Funktion programmieren kann. Sie lautet, ob sich zuverlässig zeigen lässt, dass die erzeugte Funktion unter allen relevanten Bedingungen arbeitet. Automatisierte Tests auf allen Ebenen werden dadurch wichtiger, nicht weniger wichtig.

Mehr Kontrolle bedeutet mehr Verantwortung

Die Offenheit von WooCommerce hat ihren Preis. Wer die Infrastruktur kontrolliert, muss sie auch kontrollieren können. Eine gehostete Plattform nimmt Hosting, Skalierung und einen grossen Teil der Updates ab. Bei WooCommerce liegt diese Last beim Betrieb selbst oder bei einem Dienstleister, den er dafür bezahlt. Im Panel fiel dafür der Begriff Reliability: Der Shop muss unter Last funktionieren, was geeignetes Hosting, Caching, Datenbankoptimierung, Backup-Strategien, Monitoring und Sicherheitsupdates einschliesst. An Black Friday ist die Frage, ob ein Shop theoretisch skalierbar wäre, uninteressant. Er muss laufen.

Shopify hat hier einen psychologischen Vorteil, weil eine gehostete Plattform automatisch zuverlässiger wirkt. Das stimmt insofern, als die Infrastruktur nicht in deiner Verantwortung liegt. Ausfallen können aber auch gehostete Plattformen. Der Unterschied liegt in den Handlungsmöglichkeiten: Fällt Shopify aus, bleibt nur Warten. Bei WooCommerce lässt sich eingreifen, Infrastruktur anpassen oder mit dem Hoster auf Lastspitzen vorbereiten. Das ist Vorteil und Nachteil zugleich, denn diese Kontrolle muss jemand kompetent ausüben. Wer das nicht selbst kann, braucht einen Partner dafür. Diese Kosten gehören in die Rechnung.

Diese Rechnung hat eine Kehrseite, die im Webinar offen angesprochen wurde: Was für den Betrieb Aufwand ist, ist für die Agentur Umsatz. Bei standardisierten Plattformen ist viel vorgegeben, was Einstiegskosten senkt und zugleich die Differenzierung begrenzt. WooCommerce lässt Raum für individuelle Funktionen, Wartung, Integrationen und Supportverträge. Wer die Empfehlung einer Agentur einholt, sollte diesen Interessenkonflikt kennen. Er macht die Empfehlung nicht falsch, aber er gehört auf den Tisch. Aus einer einzelnen Anforderung kann übrigens ein Produkt entstehen, wenn mehrere Betriebe dasselbe Problem haben. Ein Beispiel aus unserer Arbeit ist der Galaxus Connector für WooCommerce.

Der Kostenvergleich hält der Prüfung nur teilweise stand

Ian Misner brachte einen Punkt ein, der in Vergleichen der Gesamtkosten oft fehlt: Preismodelle von Erweiterungen skalieren unterschiedlich. Wir haben das nachgeprüft. Das Argument stimmt nur zum Teil.

Richtig ist der WooCommerce-Teil. Im offiziellen Marketplace sind Jahreslizenzen Standard, mit einer Spanne von etwa 29 bis 299 US-Dollar. Subscriptions kostet 279 Dollar im Jahr, Bookings 259, Memberships 199, AutomateWoo 159, Product Add-Ons 79. Diese Preise bleiben gleich, wenn der Händler wächst.

Zu grob ist die Behauptung, Shopify-Apps rechneten überwiegend umsatzabhängig ab. Das dominante Modell ist eine monatliche Subscription, typisch 20 bis 50 Dollar pro App. Nutzungsabhängige Abrechnung existiert aber und wächst: Shopify selbst gibt an, dass sie über 60% des Umsatzes der ertragsstärksten Apps ausmacht, etwa als Betrag pro versendeter SMS oder pro Bestellung. Seit Mai 2026 ist das Modell allgemein verfügbar.

Rechnet man nach, schrumpft der Vorsprung: 199 Dollar Jahreslizenz sind 16.58 Dollar im Monat und liegen damit im Bereich vieler Shopify-Apps. Der oft behauptete Kostenvorteil von WooCommerce ist also teilweise ein Wahrnehmungseffekt, weil eine Jahresrechnung anders wirkt als zwölf Monatsabbuchungen. Relevant wird der Unterschied dort, wo nutzungsabhängige Komponenten mit dem Bestellvolumen mitwachsen und wo ein Stack aus vielen Apps besteht.

Ähnlich verhält es sich mit dem Argument, eine gehostete Plattform mache Entwickler überflüssig. Für kleine Shops trifft das zu. Mit wachsender Komplexität bleiben Integrationen, Frontend-Anpassungen, Testing, Tracking, Datenmigrationen und Automatisierungen bestehen. Softwareentwicklung verschwindet durch die Wahl einer SaaS-Plattform nicht, sie ändert ihre Form.

Lock-in wirkt in beide Richtungen

Im Q&A kam das wohl stärkste Argument für Shopify zur Sprache. Wer einmal dort läuft und wächst, bleibt mit hoher Wahrscheinlichkeit. Neue Anforderungen lassen sich mit Apps lösen, später mit Shopify Plus. Die Kosten eines Wechsels steigen mit jedem Jahr. Das ist aus Sicht des Betriebs weder gut noch schlecht, sondern schlicht eine Bindung, die man beim Einstieg mitentscheidet.

Die Antwort des Panels war pragmatisch: Lock-in existiert überall. Auch ein grosser WooCommerce-Shop lässt sich nicht kostenlos migrieren. Der Unterschied liegt in der Granularität. Bei WooCommerce lassen sich einzelne Komponenten tauschen, etwa der Hoster, der Zahlungsanbieter oder ein einzelnes Plugin, ohne den Shop neu zu bauen. Bei einer proprietären Plattform bildet die Plattform selbst die unveränderliche Basis.

Ausgerechnet KI könnte diesen Lock-in schwächen. Migrationen bestehen zu grossen Teilen aus wiederkehrender Arbeit: Datenstrukturen analysieren, Produktdaten transformieren, URLs abbilden, Templates übertragen, Schnittstellen verbinden. Solche Aufgaben eignen sich gut für Agents. Im Webinar war von Werkzeugen die Rede, die einen grossen Teil einer Migration von Shopify zu WooCommerce automatisieren. Ob daraus eine weitgehend automatische Plattformmigration wird, muss sich zeigen. Die Richtung ist plausibel. Wenn Migrationen günstiger werden, sinkt die Macht des Lock-ins.

Agentic Commerce als zusätzlicher Kanal

Spekulativer wurde die Diskussion beim Thema Agentic Commerce. Was passiert, wenn Käuferinnen und Käufer Produkte nicht mehr selbst suchen, sondern einen Agent beauftragen, etwa mit «Bestell mir gute Laufschuhe unter 150 Franken, die bis Freitag geliefert werden»? In diesem Szenario tritt der klassische Shop in den Hintergrund. Produkte müssen so strukturiert sein, dass Maschinen sie finden, verstehen, vergleichen und kaufen können. Produktdaten, strukturierte Metadaten, Verfügbarkeit und Zahlungsprozesse gewinnen an Gewicht. Wir haben die Entwicklung in Agentic Commerce und beim Universal Commerce Protocol verfolgt.

Eine Gegenposition kam ebenfalls zur Sprache. Wenn Agents Produkte direkt vergleichen, könnte E-Commerce auf reine Infrastruktur schrumpfen: Der Händler liefert Produktdaten und konkurriert mit Hunderten Anbietern innerhalb einer KI-Oberfläche. Das Panel hält dieses Szenario nicht für die vollständige Zukunft. Menschen kaufen nicht nur Produkte, sondern teilweise Marken, Geschichten und Vertrauen. Ein eigener Shop bleibt relevant für Markenbildung, Inhalte, Kundenbindung, Abonnements, Treueprogramme und direkte Beziehungen.

Agentic Commerce wäre damit ein zusätzlicher Vertriebskanal, ähnlich wie heute Amazon, Google Shopping oder TikTok. Händler sollten ihre Produkte dort verfügbar machen können, ohne die eigene digitale Identität aufzugeben.

Wenn ChatGPT die Plattform empfiehlt

Zum Schluss fiel eine Beobachtung, die für beide Seiten gilt. Agenturen treffen Kundinnen und Kunden, die bereits mit ChatGPT oder Claude gesprochen haben und mit einer fertigen Plattformempfehlung ins Gespräch kommen. Stellt man einem Sprachmodell ohne weiteren Kontext die Frage nach der richtigen E-Commerce-Plattform, dürfte die Antwort häufig Shopify lauten.

Das ist nachvollziehbar. Shopify ist standardisiert, leicht zu erklären und für viele Projekte eine vernünftige Empfehlung. Ein Sprachmodell kennt aber weder deine Prozesse noch deine Wachstumspläne. Es antwortet mit dem statistisch häufigsten Fall. Wer diese Antwort als Ausgangspunkt nimmt und nicht als Ergebnis, fährt gut damit. Welches System bei KI-Sichtbarkeit vorne liegt, haben wir in Welches Shopsystem hat bei KI die Nase vorn? untersucht.

Einordnung

Die Diskussion kam von WooCommerce, richtete sich an Agenturen und war entsprechend gefärbt. Bemerkenswert war trotzdem, dass Shopify nicht pauschal abgewertet wurde. Vier Folgerungen für Betriebe, die vor der Plattformwahl stehen.

Die Plattformwahl an der erwarteten Entwicklung ausrichten, nicht am heutigen Lastenheft. Für einen Shop mit Standardanforderungen bleibt Shopify eine vernünftige Wahl. Je individueller Prozesse und Integrationen werden, desto stärker zählt der Zugriff auf den gesamten Stack.
Den Agent-Zugang als Auswahlkriterium mitdenken, aber den Reifegrad prüfen. Der WooCommerce MCP Server ist seit Juni 2026 verfügbar und ausdrücklich als Developer Preview gekennzeichnet. QIT setzt für die meisten Funktionen ein Marketplace-Partnerkonto voraus. Beides ist brauchbar, beides ist nicht fertig.
Nach Verifikation fragen, nicht nach Geschwindigkeit. Wenn Agents Implementierungen in Stunden liefern, verschiebt sich der Engpass auf die Frage, ob das Ergebnis unter Last, mit echten Steuersätzen und in allen Browsern funktioniert. Wer eine Offerte einholt, sollte klären, wie getestet und ausgerollt wird. Das entscheidet mehr über das Ergebnis als die reine Umsetzungsdauer.
Kostenvergleiche mit konkreten Zahlen führen. Eine Jahreslizenz von 199 Dollar entspricht 16.58 Dollar im Monat. Der Unterschied entsteht erst bei nutzungsabhängigen Komponenten und bei einem Stack aus vielen Erweiterungen, nicht durch das Lizenzmodell an sich.

Die alte Diskussion drehte sich um Freiheit gegen Komfort. KI verändert diese Gleichung, weil ein Teil der Komplexität, die bisher als Nachteil offener Systeme galt, maschinenlesbar wird. Aus «du kannst theoretisch alles ändern» wird «ein Agent findet schnell heraus, wie man es ändert». Das macht WooCommerce nicht automatisch zur besseren Plattform. Es verschiebt aber, ab welcher Projektgrösse sich der Zugriff auf den gesamten Stack auszahlt.

Quellen

Hauptbeitragsbild von Antonio Verdín.