Du hast deinen Shopify-Shop vor einigen Monaten gelauncht. Alles läuft glatt. Die Konversionsraten sind okay, die Kunden sind zufrieden. Dann, irgendwo zwischen Monat 12 und 18, merkst du: Etwas stimmt nicht mehr.
Neue Features dauern plötzlich länger. Dein Theme wird immer träger. Apps sprechen nicht miteinander. Und der Code – den niemand dokumentiert hat – ist undurchschaubar geworden.
Das ist kein Zufall. Wir nennen das das 18-Monats-Problem.
In über fünf Jahren Shopify-Entwicklung haben wir das Dutzende Male gesehen. Und wir wissen, woran es liegt: Es geht nicht um Shopify. Es geht um Architektur.
Das 18-Monats-Problem: Drei Symptome, eine Ursache
Wenn wir mit neuen Kunden sprechen, die ihr System optimieren möchten, höre ich oft die gleichen Beschwerden:
1. Theme-Flickwerk: "Unser Theme ist zur Unmöglichkeit geworden"
Der Theme – das ist die sichtbare Oberfläche deines Shops – wird bei den meisten Shops zum ersten Opfer schlechter Architektur. Hier passiert das:
- Du brauchst eine neue Landing Page. Der Entwickler modifiziert den bestehenden Theme.
- Du brauchst eine Custom Collection Page. Ein anderer Entwickler arbeitet daran.
- Nach 18 Monaten: Der Theme ist ein Konglomerat aus Customizations, Workarounds und Patches.
- Eine neue Feature dauert nicht mehr eine Woche – sie dauert drei Wochen, weil alle Abhängigkeiten verstanden werden müssen.
Ohne Struktur wird dein Theme zum Monument der technischen Schulden.
2. App-Abhängigkeiten: "Wir können kein System austauschen, ohne alles zu brechen"
Das zweite Symptom ist subtiler – aber langfristig teurer.
Statt eigener Logik verlässt du dich auf Apps. Das ist manchmal die richtige Entscheidung – aber oft nur, weil die alternative Architektur nicht geplant wurde:
- Du brauchst eine Custom Collection Page mit komplexer Filter-Logik? App.
- Du brauchst einen Custom Discount-System? App.
- Du brauchst ein Inventory-Management mit Special Rules? App.
Nach 18 Monaten: Du hast 12 Apps installiert. Sie kosten zusammen 800€/Monat. Und jede dieser Apps hat eine API mit unterschiedlichen Schnittstellen. Eine App austauschen? Das bedeutet, dass du überall, wo die App Daten speichert, Code umschreiben musst.
3. Undokumentierter Code: "Wir wissen nicht, was hier passiert"
Das dritte Problem ist das gefährlichste: Ohne klare Architektur-Entscheidungen wird Code einfach gebaut – ohne Kontext, ohne Plan.
- Warum speichert ihr diese Daten in Metaobjects?
- Warum macht ihr diese Berechnung im Theme und nicht in einem Product Variant?
- Warum gibt es 24 Collection Templates statt fünf intelligenten Templates?
Niemand kann antworten. Der Entwickler, der es gebaut hat, ist längst weg.
Was Shopify-Architektur eigentlich bedeutet
Hier müssen wir klarstellen: Shopify-Architektur ist nicht einfach "sauberer Code" oder "best practices".
Shopify-Architektur ist eine Entscheidungs-Struktur, die definiert:
- Wo deine Logik lebt (Shopify Admin, Theme, API, Custom App?)
- Wie deine Daten organisiert sind (Metaobjects? Product Variants? Custom App?)
- Welche Systeme miteinander sprechen (APIs? Webhooks? GraphQL?)
- Wann du Apps brauchst und wann du Custom Code schreibst
Die meisten Shops haben keine dieser Entscheidungen bewusst getroffen. Sie haben reagiert – auf neue Requirements, auf Zeit-Druck, auf das, was gerade am schnellsten funktioniert.
Das Resultat: Ein System, das unmöglich zu warten ist.
Ein Beispiel aus der Praxis: Bekateq
Bekateq ist ein B2B-Shop mit einer sehr speziellen Anforderung: Kunden müssen pro Artikel individuelle Mengenrabatte haben. Das ist mit Shopify's Standard-Discount-System unmöglich.
Die Wrong-Way-Lösung: Eine App kaufen, die das kann. Kosten: 200€/Monat. Automatisierung: Null.
Die Right-Way-Lösung (die wir mit Bekateq gebaut haben):
- Daten-Struktur: Custom Metaobjects für "Customer-Specific Pricing"
- Logik: Eine kleine Custom App (80 Zeilen Code), die beim Hinzufügen zum Cart die Preise anpasst
- Integration: Direkt in den Cart-GraphQL-Query – kein Umweg über externe APIs
Das Ergebnis: 4.400+ Zeilen strategischen Custom Code statt 12 teurer Apps. Maintainability: 100%. Kosten: Einen Bruchteil.
Das ist Architektur.
Metaobjects, Custom Logic, strukturierte Daten — einfach erklärt
Wenn du deine Shop-Architektur überdenken möchtest, musst du drei Konzepte verstehen:
Metaobjects: Der Daten-Container
Metaobjects sind Shopify's neueste (und beste) Antwort auf die Frage: Wie speichert man Custom Daten strukturiert?
Statt Properties auf Products zu legen (was nicht skalierten), oder JSON-Strings in product.metafields.namespace zu speichern (was unmaintainable wird), kannst du jetzt Templates definieren:
Customer Pricing
├── Customer (relationship)
├── Product (relationship)
├── Discount Percentage (number)
└── Valid Until (date)
Und Shopify speichert das strukturiert. Du kannst danach filtern, sortierten, darauf Logik bauen.
Wann du Metaobjects brauchst: Immer, wenn du Custom Daten haben möchtest, die mehreren Products oder Customers zugeordnet sind. Pricing, Bundles, Variants-Regeln, Personalisierung – das Leben in Metaobjects.
Custom Logic: Wo deine Magik passiert
Custom Logic ist nicht Theme Code. Es ist nicht eine App. Es ist die Schicht zwischen Shopify's Datenbank und deinen Customers.
Custom Logic kann sein:
- Produktlogik: Wenn ein Product A gekauft wird, muss ein Product B automatisch zum Cart hinzugefügt werden.
- Varianten-Logik: Bestimmte Kombinationen von Optionen sind nicht erlaubt.
- Pricing-Logik: Der Preis hängt von Customer-Attributen oder Mengen ab.
- Bestell-Logik: Nach dem Checkout muss etwas bestimmtes passieren.
Die Frage ist nicht "brauchst du Custom Logic" – sondern "wo lebt sie?".
Im Theme? Nein – das wird zu langsam und unmaintainable. In einer App? Nur, wenn es keinen besseren Weg gibt. In einer Custom App, die du kontrollierst? Ja – das ist Architektur.
Strukturierte Daten: Dein System als API
Gute Architektur macht deinen Shop zu einer API, nicht zu einer Black Box.
Das bedeutet:
- Deine Daten sind strukturiert (Metaobjects, nicht JSON-Strings).
- Deine Logik ist klar (Custom Apps mit einer Verantwortung, nicht monolithischer Code).
- Deine Schnittstellen sind dokumentiert (GraphQL Queries, nicht geheimer Admin Code).
Das macht es möglich:
- Neue Team-Mitglieder zu onboarden (alles ist dokumentiert).
- Neue Features zu bauen (alles ist modular).
- Systeme auszutauschen (alles basiert auf klaren APIs).
Wie wir Architektur-Projekte angehen: Echte Beispiele
Das klingt alles theoretisch. Lass mich konkret zeigen, wie das in der Realität funktioniert.
Fallbeispiel 1: J.Clay – 3 Iterationen über 5 Jahre
J.Clay ist ein Fashion-E-Commerce mit hohen Ansprüchen an Personalisierung.
Wir haben nicht alles auf einmal redesigned. Wir haben eine Architektur für Evolution gebaut:
Iteration 1 (2020): Grundstruktur
- Metaobjects für Größen-Tabellen
- Custom App für Size-Prediction-Logic
- Klare Trennung: Theme macht Rendering, Custom App macht Logic
Iteration 2 (2022): Scale
- Neue Metaobjects für Customer-Preferences hinzugefügt
- Custom App wurde um Personalisierungs-Engine erweitert
- Kein Theme-Refactor nötig – alles läuft über neue APIs
Iteration 3 (2024): Performance & Intelligence
- GraphQL Queries optimiert (vorher: 500ms für Collection Page, nachher: 120ms)
- AI-basierte Recommendation-Engine hinzugefügt (wieder: über Custom App)
- Theme war nie ein Bottleneck
Das Resultat: +107% Umsatzwachstum in 5 Jahren. Und das Theme? Das gleiche wie 2020, nur optimiert.
Das ist gute Architektur.
Fallbeispiel 2: Bekateq – Von 12 Apps zu 0
Bekateq ist ein B2B-Shop mit komplexen Anforderungen. Sie hatten 12 Apps installiert – alle versuchten, verschiedene Teile eines fehlenden Architektur-Plans zu füllen.
Wir haben einen Architektur-Plan gebaut:
Apps: 0 (ernsthaft) Custom Metaobjects: 8 (Customer-Pricing, Volume Pricing, Approved Vendors, etc.) Custom Code: 4.400+ Zeilen über 4 Custom Apps Collection Templates: 24 (nicht 12.000 CSS-Hacks) Monthly Costs: Runter von 2,5k € auf 400€
Und der wichtigste Punkt: Das System ist wartbar. Jede Custom App hat eine Verantwortung. Jedes Metaobject hat einen Grund zu existieren. Jedes Template hat ein Ziel.
Wenn eine neue Person das Team joint, kann sie in zwei Wochen produktiv arbeiten – nicht nach zwei Monaten.
Checkliste: Braucht mein Shop eine Architektur-Revision?
Wenn du eins oder mehr dieser Punkte erkennst, dann ja:
- Dein Shop ist älter als 12 Monate und neue Features dauern länger als am Anfang
- Du hast mehr als 8 Apps installiert
- Dein Theme-Code ist > 5.000 Zeilen (ohne Dependencies)
- Du verwendest JSON-Strings in Metafields statt Metaobjects
- Deine Entwickler können nicht erklären, "warum" etwas so gebaut wurde
- Du zahlst mehr als 1k €/Monat für Apps, die nur eine Sache machen
- Eine neue Collection-Page-Variante brauchte mehr als eine Woche
- Dein Shop hat Custom-Logik, die "irgendwie funktioniert, aber niemand versteht es"
- Du hast mehrere Versionen von ähnlichen Templates (z.B. 5 verschiedene Collection-Pages)
- Ein Feature zu ändern erfordert, Code an 3+ verschiedenen Stellen zu updateen
3+ Häkchen? Du brauchst eine Architektur-Revision.
Und ja, das kostet Zeit und Geld. Aber es kostet weniger als ein System zu have, das langfristig unmaintainable wird.
Was wir mit deinem Shop machen würden
Wenn du mit uns über eine Architektur-Revision sprichst, gibt es einen klaren Prozess:
Phase 1: Audit (1-2 Wochen)
Wir schauen uns deinen aktuellen Shop an:
- Code-Review
- App-Audit
- Daten-Struktur-Analyse
- Performance-Testing
Resultat: Ein Bericht, der zeigt, wo die Probleme sind.
Phase 2: Architektur-Planung (2-4 Wochen)
Wir bauen einen neuen Plan:
- Welche Apps können weg? (und wie?)
- Wo braucht es Custom Code?
- Welche Metaobjects sind nötig?
- Wie wird die Migration durchgeführt?
Resultat: Eine technische Roadmap, auf der wir beide einig sind.
Phase 3: Implementierung (6-12 Wochen)
Wir bauen:
- Neue Metaobjects
- Custom Apps
- Refactored Theme (falls nötig)
- Migration der alten Daten
Resultat: Ein wartbarer, zukunftssicherer Shop.
Unsere Architecture+ Service startet ab 10k € und beinhaltet alle drei Phasen.
Die unbequeme Wahrheit
Gute Shopify-Architektur ist nicht sexy. Es gibt keine Folien, die man auf LinkedIn teilen kann. Es ist keine neue App, kein neuer Feature.
Es ist Handwerk. Es ist Planung. Es ist das Gegenteil von "schnell gehackt".
Aber es ist auch das Unterschied zwischen einem Shop, den du in 5 Jahren einfach skalieren kannst – und einem Shop, dessen Komplexität dir entgleitet.
Wir haben beide Arten gesehen. Wir wissen, welche besser ist.
Wenn dein Shop älter wird und du merkst, dass etwas nicht stimmt, ist es Zeit, darüber nachzudenken. Nicht nächstes Jahr. Jetzt. Bevor das 18-Monats-Problem dich einholt.
Über Claudio Gerlich
Claudio Gerlich ist Gründer von smplx. und technischer Shopify-Partner seit 2020. Aus Coesfeld, NRW, hat er über 50 Enterprise-Shops architekturiert und optimiert. Seine Expertise liegt in der Planung von Systemen, die nicht zusammenbrechen – selbst wenn der E-Commerce wächst.
Wenn du über deine Shop-Architektur sprechen möchtest, schreib uns.