In Arbeit · Kunde: Internal process, used for client stores

F1-Boxenstopp: Ein Shopify-Store, von allen Seiten gleichzeitig gebaut

Wie eine Boxencrew bauen parallele KI-Agenten Frontend, Produkte, Medien und Einstellungen eines Stores gleichzeitig aus einem Briefing – und ein Prüfer gibt das Ergebnis frei.

KI-Automatisierung Maßgeschneiderte KI-Agenten E-Commerce

F1 Pit Stop: Building a Shopify Store From Every Side at Once

Ergebnis

Ein Briefing hinein, ein launchfertiger Entwurf heraus – von der Kundin geprüft, bevor etwas live geht.

Kurz gesagt

Ein Input: ein Briefing, ein Ordner mit Produktmedien und Zugang zum Store.
Vier Crews parallel: Frontend, Produkte, Medien sowie Backend/Funktionen – dazu ein Prüfer, der das Ergebnis mit dem Briefing vergleicht.
Ein Output: ein launchfertiger Store als Entwurfs-Theme, das die Kundin ansehen kann, bevor etwas live geht.

Das Problem

Ein normaler Shopify-Aufbau ist ein Staffellauf: erst Marke und Theme, dann Produkte, dann Fotos, dann Apps und Einstellungen, dann Texte, dann Qualitätskontrolle. Jede Übergabe wartet auf die vorige, deshalb dauert das Ganze Wochen. Dabei hängen die meisten Schritte gar nicht voneinander ab: Das Theme braucht keine finalen Produkttexte, und die Produktanlage braucht kein Theme.

Der Ablauf

1. Das Briefing (der Wagen fährt in die Box)

Alles kommt aus einem strukturierten Input: - Marke: Name, Tonalität, Farben, Referenz-Stores, - Produkte: Namen, Varianten, Preise, Spezifikationen, - Medien: rohe Produktfotos und -videos, - Zugang: Admin-API-Token und Shopify-CLI-Zugang.

2. Die Crews (alle gleichzeitig)

Crew	Was sie baut
Frontend	Ein eigenes Liquid-Theme: Startseiten-Bereiche, Produktseite, Kollektionsraster und Warenkorb in Farben und Schrift der Marke. Immer auf einer Entwurfskopie, nie auf dem Live-Theme.
Produkte	Produkte, echte Varianten (Größe / Farbe / Menge als Optionen, nicht als eigene Produkte), Beschreibungen, SEO-Felder und Kollektionen – alles über die Admin GraphQL API.
Medien	Freisteller, Lifestyle-Bilder, Mockups und ein Media-Kit aus den Rohfotos, den richtigen Produkten zugeordnet.
Backend & Funktionen	Apps und Einstellungen: Bewertungen in Judge.me importiert, Versand- und Rechtsseiten, Navigation, Metafelder, Integrationen.

3. Der Prüfer (der Mann mit der Kelle)

Ein eigener Agent öffnet den Store wie eine Kundin und vergleicht ihn mit dem Briefing: jede Produktseite, jede Kollektion, jeder Link. Was fehlt, geht an die zuständige Crew zurück – bis die Checkliste grün ist.

4. Freigabe

Die Kundin bekommt einen Vorschau-Link zum Entwurfs-Theme und einen kurzen Vorher-Nachher-Bericht. Nach ihrer Freigabe wird veröffentlicht.

Unter der Haube

Zugangsdaten pro Store. Jeder Store hat einen eigenen Satz Zugangsdaten. Seit Shopify im Jänner 2026 die alten Custom Apps eingestellt hat, kommen die Tokens über eine App im Dev Dashboard und den OAuth-Ablauf.
Ein gemeinsamer API-Client. Ein kleiner Node.js-Client kümmert sich um Paginierung, Ratenbegrenzung und Fehler – jede Crew spricht gleich mit Shopify.
Immer zuerst als Entwurf. Die Shopify CLI kopiert das Live-Theme und schreibt Änderungen nur in die Kopie. Der Live-Store wird nie direkt bearbeitet.
Große Medien außerhalb von Git. Rohmedien (~900 MB pro Store) liegen in Google Drive. Das Repository enthält nur Code, Themes und erzeugte Assets.
Lehren im Prüfer verankert. Typische Importfehler werden automatisch getestet: Varianten als eigene Produkte angelegt, fehlende Artikelnummern und Gewichte, englischer Text im deutschen Shop, Platzhalter in Bereichen, tote Menülinks.

Warum es funktioniert

Standardmäßig parallel. Die Crews teilen sich nur Briefing und API-Client und blockieren sich deshalb nicht.
Der Prüfer macht Parallelität sicher. Tempo ohne Endkontrolle würde nur Fehler schneller ausliefern.
Entwurfs-Themes sind kundenfreundlich. Die Kundin prüft einen echten, klickbaren Store statt Mockups.