Shopify, WooCommerce oder eigene Lösung – wann sich Skibidoo lohnt und für wen
Es hat mehrere Anläufe gebraucht. WooCommerce ist das Produkt, von dem ich in Kundenprojekten immer wieder weg wollte: zu starre Vorgaben, ein Plugin-Ökosystem das Erweiterungen verspricht und Komplexität liefert, und eine Codebasis, die mit PHP und WordPress mitaltert. Shopify biete ich nicht an – Transaktionsgebühren, fehlende Kontrolle über Datenstruktur und Deployment passen nicht zu der Art, wie ich Projekte aufbaue. Next.js als Alternative scheidet ebenfalls aus, aus denselben Gründen die ich anderswo beschrieben habe: zu viel Framework, zu viel Overhead für das, was ein Shop wirklich braucht.
Was jetzt funktioniert hat: Skibidoo, ein Prototyp auf Basis des AHA-Stacks, gebaut aus Komponenten, in denen ich mich auskenne. Kein Greenfield-Experiment aus der Theorie heraus, sondern der Versuch, WooCommerce bei bestehenden Kunden schrittweise ablösen zu können.
Warum Kunden trotzdem bei Shopify und WooCommerce landen
Das heißt nicht, dass diese Plattformen schlechte Antworten sind – sie lösen echte Probleme, nur nicht die, die für meine Arbeit relevant sind.
Shopify löst Zeit: Ein Shop in wenigen Stunden, keine Serverkosten, kein Deployment. Für ein Team ohne technische Ressourcen ist das ein klarer Vorteil. Die Kehrseite akkumuliert sich still: Transaktionsgebühren auf jeden Umsatz, monatliche Kosten für Features die woanders kostenlos sind, eine Theme-Architektur die Eigenentwicklung erschwert.
WooCommerce hat seinen Reiz: Installation in wenigen Schritten, kein Lizenzvertrag, das Gefühl von Unabhängigkeit. Dieses Gefühl hält, bis man ein Theme anpassen muss – oder von den Updates eines gekauften Themes abhängig wird. Bei Plugins läuft es ähnlich: Was kostenlos ist, bekommt im Zweifel irgendwann keine Updates mehr. Support läuft in erster Instanz über eine Agentur, in zweiter über den Plugin-Entwickler – das geht oft gut. Aber ein einziger Showstopper reicht.
Dazu kommt, dass viele Plugins für den amerikanischen Markt entstehen und nicht ohne Weiteres auf europäische oder deutsche Anforderungen passen. Nach langen Jahren mit WooCommerce zwingt genau das dazu, immer mehr eigene Plugins in einem System zu entwickeln, das nicht mehr zeitgemäß ist. Das ist der eigentliche Punkt: Wenn zwischen einem Kunden und einer Funktion eine 1:1-Abhängigkeit zu einem fremden Plugin entsteht, ist die Kontrolle weg.
Die Entscheidung fällt vor der Technik
Bevor es um Stack-Wahl geht, steht eine Frage auf Betreiberebene: Verkauft man besser über eine Standardlösung – oder mit einer individuell angepassten? Beide Wege funktionieren. Die Antwort liegt nicht in der Technologie, sondern in Produkten, Nische und Wettbewerb. Diese Entscheidung bewusst zu treffen, erfordert Einarbeitung in die Materie. Wer sie nicht trifft, trifft sie trotzdem – nur implizit.
Zur Entscheidung gehört auch eine Rechnung: Was ist der zu erwartende Umsatz – und was bleibt davon nach Plattformkosten, Transaktionsgebühren und laufenden Kosten übrig? Reicht das, um einen Entwickler zu beauftragen, der sich zu welchem Anteil um den Shop kümmern kann? Ein Budget sollte nicht aus der Technologie heraus bestimmt werden, sondern aus dem Ziel. Ein Gespräch mit jemandem, der verschiedene Umsetzungswege kennt, hilft dabei: nicht als Verkaufsgespräch, sondern als technische Orientierung – um realistisch einzuschätzen, welcher Weg zur Situation passt.
Die Zielgruppe für eine individuelle Lösung ist nicht derjenige, der schnell starten oder Kosten sparen will. Es ist derjenige, der weiß, dass sein Wettbewerb dieselben Themes, dieselben Plugin-Grenzen und dieselbe Shop-Logik verwendet – und der daraus einen anderen Schluss zieht. Wer sich abheben will, reaktiv auf Marktveränderungen reagieren will und keine Abhängigkeiten aufbauen möchte die später teuer werden, braucht mehr Kontrolle als Standardlösungen hergeben.
Was eine individuelle Lösung konkret besser kann
Geschwindigkeit: Eine statisch gerenderte Seite lädt schneller als jede PHP-basierte WooCommerce-Instanz oder Shopify-Theme – strukturell, nicht durch Optimierungstricks. Core Web Vitals sind kein Konfigurationsproblem, sondern ein Architekturproblem. Das wirkt sich auf Conversion aus.
WCAG-Konformität und rechtliche Absicherung: Barrierefreiheit lässt sich von Anfang an einbauen, statt sie nachträglich in Theme-Strukturen einzupassen, die dafür nicht gedacht sind. Das ist nicht nur eine Qualitätsfrage — seit Juni 2025 gilt das Barrierefreiheitsstärkungsgesetz (BFSG), das Onlineshops zu WCAG-Konformität verpflichtet. Wer das nicht proaktiv umsetzt, riskiert Abmahnungen. Eine individuelle Lösung ermöglicht es, rechtliche Anforderungen — Barrierefreiheit, DSGVO-konforme Cookie-Implementierung, korrekte Preisangaben, AGB-Integration — als Teil der Architektur zu behandeln, nicht als Plugin-Flickwerk.
Bildoptimierung: Moderne Formate, automatisches srcset, Lazy Loading ohne Plugin-Overhead – als Teil der Architektur, nicht als nachträgliche Konfigurationsaufgabe mit unklarer Zukunft.
Strukturierte Daten: Product-, Offer- und Review-Schema passend zur Branche und zum Sortiment – nicht aus einem generischen Plugin, sondern als Teil der Seitenlogik. Mit KI-gestützter Suche wird das entscheidender: Wer Produktdaten sauber strukturiert, ist besser positioniert als wer auf klassischen Suchmaschinen-Traffic oder Amazon-Sichtbarkeit setzt, die sich jederzeit verschieben kann.
Schnittstellen zu Vertriebskanälen: Eigene API-Logik, eigene Datenstruktur – keine Abhängigkeit zu Drittanbieter-Plugins, die für den amerikanischen Markt entwickelt wurden und europäische Anforderungen oft nur halbgar abdecken.
Für wen das konkret passt
Direktvertrieb kleiner Manufakturen: Wer 200–500 SKUs verkauft, eigene Preislogik hat und keine Plattform-Transaktionsgebühren zahlen will, rechnet schnell nach. Bei 100.000 Euro Jahresumsatz sind das je nach Plan 2.000–3.000 Euro allein für die Plattform.
B2B-Shops mit Sonderkonditionen: Kundenspezifische Preise, Rabattgruppen, Bestelllimits per Account – in Shopify entweder teuer (Plus-Plan) oder umständlich. In einer eigenen Lösung ist es Datenbanklogik.
Existenzgründer die von Anfang an richtig aufstellen wollen: Wer neu startet, kann Abhängigkeiten selbst gestalten – statt sie geerbt zu bekommen. Auch eine Eigenentwicklung ist eine Abhängigkeit, und im besten Fall bedeutet das einen prozentualen Anteil am Umsatz für laufende Entwicklung und Pflege. Wer zu knapp kalkuliert, kann sich einen Shop möglicherweise nicht leisten – und setzt sich damit nicht gegen die Konkurrenz durch. In Deutschland ist es kulturell noch nicht selbstverständlich, einen eigenen Shop zu starten. Wer es trotzdem tut und dabei auf individuelle Kontrolle setzt, hat die beste Ausgangsposition – aber nur, wenn das Budget realistisch ist.
Skibidoo als eine Umsetzungsmöglichkeit
Es gibt mehrere Wege, eine individuelle E-Commerce-Lösung zu bauen. Skibidoo ist einer davon – ein Prototyp auf Basis des AHA-Stacks, der aus Komponenten besteht, in denen ich mich auskenne, und der die oben beschriebenen Vorteile in einer konkreten Implementierung zusammenführt.
Der Stack:
- Astro übernimmt das Frontend: statisch gerendert, schnell, kein JavaScript-Overhead für das Template
- HTMX + Alpine.js für interaktive Elemente ohne SPA-Overhead: Warenkorb-Updates, Formularvalidierung
- Bun als Runtime: schneller als Node.js, kompatibel mit dem Node-Ökosystem
- Hono als API-Framework: leichtgewichtig, Edge-ready
- Drizzle ORM für typsichere Datenbankzugriffe
Das Ergebnis ist ein Stack, der sich für statische Sites performant anfühlt und gleichzeitig vollständige E-Commerce-Funktionalität mitbringt: Produktkatalog, Warenkorb, Checkout, Stripe- und PayPal-Integration, Transaktions-E-Mails, Lagerverwaltung, Rabattcodes.
Eine erwähnenswerte Alternative zwischen Standardlösung und Vollentwicklung ist Snipcart: kein vollständiges Shop-System, sondern ein JavaScript-basierter Warenkorb, der sich in jede statische Site integrieren lässt. Das Bezahlsystem ist managed, die Kontrolle über das Frontend bleibt vollständig. Transaktionsgebühren fallen an – aber das Modell löst den technisch schwierigsten Teil ohne eigene Infrastruktur. Für kleinere Sortimente, als schneller Einstieg oder als Zwischenschritt ist das ein realistischer Weg, der technisch mehr eigenes Potenzial ermöglicht als Shopify oder WooCommerce.
Die Entscheidungsmatrix
| Kriterium | Shopify | WooCommerce | Individuelle Lösung |
|---|---|---|---|
| Setup-Aufwand | Niedrig | Mittel | Hoch |
| Laufende Kosten | Mittel–Hoch | Scheinbar niedrig | Niedrig |
| Transaktionsgebühren | Ja | Nein | Nein |
| Technische Kontrolle | Gering | Mittel | Vollständig |
| WCAG / Performance | Plugin-abhängig | Plugin-abhängig | Architekturell |
| Strukturierte Daten | Generisch | Generisch | Branchenspezifisch |
| EU-Markteignung | Gut | Plugin-abhängig | Vollständig steuerbar |
| Dev-Erfahrung nötig | Nein | Wenig | Ja |
Was es nicht ersetzt
Ehrlichkeit gehört dazu: Skibidoo ist kein Shopify-Ersatz für Teams ohne technisches Know-how. Deployment, Datenbank-Management, Updates – das liegt in eigener Hand. Support-Ökosystem, App-Store, Design-Themes – fehlen.
Wer einen Shop in einer Woche live haben will und danach nie mehr am Code arbeiten möchte, ist bei Shopify besser aufgehoben.
Zur Transparenz gehört noch etwas: Der ideale Skibidoo-Kunde – jemand der komplett neu startet und dessen Shop von Grund auf gebaut werden kann – existiert im eigenen Kundenstamm noch nicht. Der häufigere Fall ist die Migration eines bestehenden WooCommerce-Shops, und die hat ein echtes Risiko: laufende Funktionen, laufender Umsatz, gewachsene Kundenerwartungen. Bei der aktuellen Marktlage ist ein E-Commerce-Neustart außerdem kein risikofreies Vorhaben – das hängt stark an Produkten, Nische und Wettbewerb. Das ist kein Argument gegen den Schritt, aber ein Argument dafür, ihn sorgfältig zu planen.
Wer technische Kontrolle und niedrige laufende Kosten will, findet im AHA-Stack eine ernsthafte Alternative – sobald das Risiko einschätzbar ist.
Die Fragen rund um Technologie, Budget und Abhängigkeiten gehen dabei Hand in Hand mit einer grundlegenderen Frage: ob ein eigener Shop überhaupt das richtige Vertriebsmodell ist – und was es bedeutet, ihn zu betreiben. Das ist keine Frage, die ich für einen Kunden beantworte, aber eine, die ich stelle. Shopify oder WooCommerce? Falsche Frage. geht darauf ein, warum die klassische Plattformdebatte oft am eigentlichen Thema vorbeigeht.
Letztendlich entscheidet der Kunde. Was ich beitragen kann, ist ein Grundverständnis dafür, was zum Betrieb eines Shops wirklich dazugehört – technisch, wirtschaftlich, strategisch. Und wer mit einem durchdachten Konzept und einem klaren Portfolio kommt, findet hier eine gute Ausgangsbasis.