Shopify-Shop in 4 Tagen: Die ehrliche KI-Story
Wir haben einen kompletten Shopify-Shop in 4 Arbeitstagen mit Claude Code gebaut. Nicht als Demo. Nicht auf einer Testseite. Sondern als echten, funktionierenden Online-Shop — live zur Messe, mit 12 Produkten, 31 Varianten, drei Marken und vollem Custom Design.
Was funktioniert hat, was schiefging, und warum das nächste Projekt noch schneller wird.
Die Ausgangslage
Wir suchen seit zwei Jahren nach dem richtigen Projekt. Nicht nach irgendeinem — nach einem, das zeigt was passiert, wenn man KI-gestützte Shopentwicklung unter echtem Zeitdruck einsetzt. Intern hatten wir dutzende Test-Shops gebaut, Skills und Workflows entwickelt, Sicherheitschecks automatisiert. Aber ein Testprojekt ohne Deadline ist kein Beweis. Es ist eine Übung.
Warum wir das nur auf Shopify machen und nicht auf anderen Plattformen, haben wir in unserem Plattform-Vergleich zur KI-Entwicklung 2026 ausführlich erklärt.
Der Kunde verkauft Frequenz-Resonanzprodukte unter drei Marken: NERAGO (Wasserbelebung), ZENTARI (Balance-Matten und Chakren-Elemente) und SYNIVA (zyklusbegleitende Produkte). 12 Produkte, 31 Varianten, ein Sortiment das erklärungsbedürftig ist und optisch überzeugen muss.
Der bestehende Shop lief auf WooCommerce mit Breakdance Page Builder. Plugin-Landschaft aus FunnelKit, Solid Affiliate und diversen Erweiterungen. PageSpeed Mobile: 65. Die Seite war langsam, unübersichtlich und visuell nicht auf dem Niveau, das die Produkte verdienen.
Dann kam der Auslöser: Eine Messe stand an. Am Wochenende würden hunderte potenzielle Kunden den Shop besuchen — und der alte Shop war nicht vorzeigbar.
Unter normalen Umständen: nicht machbar in der Kürze der Zeit. Genau deshalb der perfekte Testcase.
Der Prozess: 4 Arbeitstage, 81 Commits
Tag 1 (02. April): Das Fundament
21 Commits an einem Tag. Dawn als Basis-Theme, darauf aufbauend: ein komplettes Design-System mit Markenfarben (Gold, NERAGO-Petrol, ZENTARI-Violett, SYNIVA-Rosé), Typografie (Cormorant Garamond für Headlines, Inter für Body) und CSS-Variablen als Single Source of Truth.
Parallel dazu alle Custom Sections: Hero, Brand Cards, Trust-Bar, Newsletter, Footer, FAQ mit Schema.org, Content Left-Right, Produktgalerie nach Best-Practice-Vorbildern, Trust-Icons, Chakra-Grid. Dazu SEO Schema Markup (Product, Organization, Breadcrumb), Kategorie- und Markenseiten, die komplette Homepage.
Am Ende von Tag 1 stand die Architektur. Jede Seite hatte ihr Template, jede Section ihre Logik. Kein Pixel war fertig designed — aber die Struktur war belastbar.
Tag 2 (07. April): Produkte und Content
Die Datenmigration begann mit einem Trick: Die WooCommerce Store API (/wp-json/wc/store/v1/products) liefert Produktdaten ohne Authentifizierung. Einzelne Varianten mit Preisen über die Varianten-Endpoints. Schneller als manuelles Scrapen, zuverlässiger als CSV-Export.
12 Produkte und 31 Varianten migriert. Dann der Teil der normalerweise Tage dauert: Produkttexte.
3 parallele KI-Agenten — einer pro Marke — generierten rechtskonforme Produktbeschreibungen. NERAGO (8 Produkte) brauchte circa 8 Minuten, ZENTARI und SYNIVA je circa 2,5 Minuten. Gesamt: unter 9 Minuten statt geschätzter 30 Minuten bei serieller Bearbeitung.
Jeder Text wurde auf HWG-Konformität geprüft. Bei Frequenz-Resonanzprodukten ist das nicht optional — das ist der Unterschied zwischen einem Shop der läuft und einer Abmahnung. "Anwender berichten" statt "wirkt gegen". "Kann unterstützend eingesetzt werden" statt "heilt". Immer: "Kein Medizinprodukt."
Tag 3 (10. April): Feinschliff und QA
70 Produktfotos — einheitlich auf 2000px aufbereitet, responsive eingebunden. Die Produktdetailseite wurde komplett nach definierten Best-Practice-Vorbildern redesigned: Trust-Icons in der Buybox, ausklappbare Tabs für Technologie/Versand/Hinweise, Content-Left-Right-Sektionen mit Lifestyle-Bildern, MwSt-Hinweise, Payment-Icons.
Ein QA-Review deckte Detailfehler auf: falsche Navigationsfarben, fehlende Brand-Card-Links, Chakren-Bildswatches die nicht funktionierten. Alles behoben, alles dokumentiert.
Tag 4 (12. April): Collection-Landingpages und Launch
Der letzte Tag war der intensivste: 29 Commits. 3 markenspezifische Collection-Landingpages mit KI-generierten Hero-Bildern und Content-Sektionen. Dazu markenspezifische PDP-Templates — jede Marke mit eigenen Lifestyle-Bildern in den Content-Sektionen.
Jedes generierte Bild durchlief einen Freigabe-Prozess: Alle Bilder auf einer HTML-Seite gesammelt, visuell geprüft, problematische Motive markiert, erst nach Freigabe deployed.
Live-Deployment — rechtzeitig zur Messe.
Was schiefging
Vier Arbeitstage klingen nach einer Erfolgsstory. Und das ist es auch. Aber nicht, weil alles reibungslos lief — sondern weil wir wussten wie man mit den Problemen umgeht.
KI-generierte Inhalte brauchen Qualitätskontrolle
Bilder und Texte kommen nicht fertig aus dem Modell. Jedes Bild wurde visuell geprüft, jeder Text auf HWG-Konformität kontrolliert.
Konkret: Imagen generierte manchmal komplett falsche Motive — ein Hero-Bild für die Wasserfilter-Kategorie zeigte einen Burger statt einer Küche. Ein anderes Hero-Bild hatte eingebettete Thumbnails mit URL-Text als Artefakt. Syniva-Bilder zeigten Männer bei einem Produkt, das sich an Frauen richtet. Fünf Korrektur-Runden waren nötig, bis alle Bilder stimmten.
Deployment-Prozesse müssen abgesichert sein
Shopify-Themes haben Eigenheiten, die bei schnellem Arbeiten zu Datenverlust führen können. Daraus haben wir automatische Sicherheitschecks gebaut.
Zwei kritische Vorfälle: Ein Theme-Push löschte alle Content-Bilder die nur auf Shopify existierten, aber nicht im lokalen Git-Repository lagen — die PDPs waren plötzlich bilderlos. Und beim ersten Push überschrieb der Befehl die settings_data.json — Logo, Farben und Custom-Einstellungen waren weg. Beide Probleme gelöst: .shopifyignore für Settings, und ein Pre-Deploy-Script das prüft ob alle referenzierten Assets vorhanden sind.
KI macht selbstbewusst Fehler
Kostenloses Playbook
E-Com KI-Wachstums-Playbook 2026
4 KI-Tools + 7 Custom GPTs — aus 150+ Shopify-Projekten entwickelt. Konkret, sofort nutzbar, kostenlos.
Jetzt kostenlos sichernOhne Verifikationsschritte geht das schief. Jeder KI-Output braucht einen Check — nicht weil die KI schlecht ist, sondern weil sie keine Zweifel kennt.
Beispiel: Ein Agent sollte ein Produkt umbenennen und bekam die IDs aus einer früheren Abfrage. Die Reihenfolge der API-Ergebnisse war nicht stabil — der Agent benannte versehentlich ein Produkt falsch, weil er die IDs nicht gegen die Produkt-Handles verifiziert hatte. Sofort bemerkt, sofort revertiert. Seitdem: Jede Mutation wird per productByHandle-Lookup gegen-verifiziert, bevor sie ausgeführt wird.
Diese Fehler konnten wir so schnell lösen, weil wir nicht bei Null angefangen haben.
Vorher: WooCommerce mit Breakdance Page Builder
Die Homepage war ein Sammelsurium: große Textblöcke, keine klare Hierarchie, die drei Marken gingen im Layout unter. Auf Mobile (PageSpeed 65) dauerte der erste sichtbare Aufbau spürbar lang.
Die Produktseiten nutzten das WooCommerce-Standard-Layout. Keine Trust-Signale in der Buybox, keine erklärenden Content-Sektionen unter dem Produkt, keine FAQ. Bei erklärungsbedürftigen Produkten wie Frequenz-Resonanz-Geräten fehlt damit der Kontext, den Kunden für eine Kaufentscheidung brauchen.
Nachher: Shopify mit Dawn-basiertem Custom Theme
Die Homepage führt mit einem Split-Hero direkt in die Markenwelt. Darunter: Brand Cards für NERAGO, ZENTARI und SYNIVA mit den jeweiligen Markenfarben. Bestseller-Produkte, Trust-Bar, Newsletter-Sektion — alles in einer klaren visuellen Hierarchie.
Die Produktdetailseiten folgen bewährten Best-Practice-Mustern: illustrative Trust-Icons in der Buybox, ausklappbare Tabs (Technologie, Versand, Hinweise), Content-Left-Right-Sektionen mit Lifestyle-Bildern, FAQ mit Schema.org-Markup. Jede Marke hat ein eigenes PDP-Template mit passenden Bildern.
Die Zahlen
| Kennzahl | Wert | |---|---| | Arbeitstage | 4 (verteilt auf knapp 2 Wochen) | | Commits | 81 | | Produkte migriert | 12 | | Varianten | 31 | | Collections | 3 | | Custom Sections | 14 | | Content-Agenten parallel | 3 | | Texterstellung (12 Produkte) | unter 9 Minuten | | Produktfotos aufbereitet | 70 | | Live zur Messe | Ja |
> "Das hat ein ganz anderes Niveau." > "Sensationell." > — Joachim Janssen, Inhaber 3 ZENSES
Die geheime Zutat — 2 Jahre Vorbereitung
Claude Code kann jeder kaufen. Ein Abo abschließen, den Editor öffnen, loslegen. Trotzdem baut niemand damit in vier Tagen einen kompletten Shop. Der Unterschied ist nicht das Tool — der Unterschied ist das System drumherum.
Seit zwei Jahren bauen wir intern die Infrastruktur auf. Nicht als Nebenprojekt, sondern als strategische Investition.
Was das konkret bedeutet
- —CLAUDE.md als Projekt-Betriebssystem: Jedes Projekt hat eine Datei die dem KI-System sagt wer der Kunde ist, welche Regeln gelten, welche Fehler zu vermeiden sind. Bei diesem Projekt enthielt sie HWG-Compliance-Regeln, Design-Referenzen, Shopify-Konventionen und die komplette Marken-Architektur. Die KI arbeitet nicht im luftleeren Raum — sie arbeitet in einem definierten Rahmen.
- —Skills als wiederverwendbare Bausteine: Migration-Checkliste, QA-Review, SEO-Audit, Schema-Markup, Copywriting — alles abrufbar per Befehl. Kein Copy-Paste aus alten Projekten, kein "wie haben wir das nochmal gemacht?"
- —Hooks als Sicherheitsnetz: Vor jedem Deploy auf Shopify läuft automatisch ein Validierungs-Script (validate-theme.py). Es prüft ob alle Asset-Referenzen existieren, ob Produkt-Handles und Collection-Handles gültig sind. Wenn etwas fehlt, wird der Deploy blockiert.
- —LEARNINGS.md als Projektgedächtnis: Jede Session schreibt ihre Erkenntnisse in eine strukturierte Datei — was funktioniert hat, was schiefging, was besser werden muss. Das nächste Projekt startet nicht bei Null, sondern bei dem was wir gelernt haben.
Das Tool kann jeder kaufen. Das System dahinter nicht.
Das lernende System
Am Tag nach dem Launch war das Projekt nicht abgeschlossen — es hatte gerade erst angefangen zu wirken.
Die LEARNINGS.md aus diesem Projekt enthält 40+ dokumentierte Patterns, Fehler und Verbesserungen. Daraus entstanden
- —Neue Skills: Der Bildfreigabe-Prozess ist jetzt ein standardisierter Workflow — Batch-Generierung, Freigabe-Seite, erst nach Approval wird deployed.
- —Neue Hooks: .shopifyignore für settings_data.json wird bei jedem neuen Projekt automatisch eingerichtet. Das Pre-Deploy-Validierungs-Script ist Standard.
- —Neue Patterns: productByHandle-Lookup vor jeder Mutation. first: 100 als Default bei Varianten-Queries. Parallel-Agenten mit explizitem ID-Mapping statt Slug-Keys.
Das ist der eigentliche Unterschied zu einem normalen Agentur-Projekt. Bei einem normalen Projekt lernt der Projektleiter. Hier lernt das System. Das nächste Projekt profitiert nicht davon, dass jemand sich erinnert — es profitiert davon, dass die Regeln geschrieben sind.
Migration ist Startpunkt, nicht Finale
Ein Shop ist ein System. Systeme werden nicht fertig — sie werden besser oder schlechter.
Die Migration hat eine belastbare Grundlage gegeben. Aber die echten Hebel kommen danach: Conversion-Optimierung basierend auf echten Daten. Content-Erweiterungen für erklärungsbedürftige Produkte. E-Mail-Flows für Wiederkäufe. SEO-Aufbau für organischen Traffic.
KI-gestützte Betreuung verändert fundamental, was nach einem Launch möglich ist. Nicht weil KI zaubern kann — sondern weil Aufgaben, die vorher Stunden dauerten, jetzt in Minuten erledigt sind. Ein A/B-Test aufsetzen? Eine Produktseite für ein neues Produkt erstellen? Texte für eine Landingpage generieren und HWG-konform prüfen? Das sind keine Projekte mehr. Das sind Routinen.
Die eigentlichen Gewinner liegen nicht in der Migration — sondern in dem, was danach kommt.
Die nächsten Projekte laufen bereits — mit unterschiedlichen Schwerpunkten, anderen Branchen, anderen Herausforderungen. Was gleich bleibt: Jedes Projekt macht das System besser.
