Ein E-Commerce-Projekt mit unerwarteter Wendung
Ein moderner Onlineshop, insbesondere ein Headless-Shop, besteht nicht nur aus Produktbildern und einem funktionierenden Warenkorb. Dahinter stehen technische Architektur, Nutzererlebnis, Performance, rechtliche Vorgaben und wirtschaftliche Entscheidungen.
Im Rahmen unseres Hochschulprojekts entwickelten wir für die Marke SOLIT einen performanten Headless-Shop. Das Konzept bestand aus einem individuell programmierten Frontend, einem Shopsystem im Hintergrund und einem E-Commerce Layer als verbindendem Element.
Während der technischen Umsetzung zeigte sich jedoch, dass einige unserer ursprünglichen Annahmen nicht vollständig aufgingen. Plötzlich standen wir vor einer grundlegenden Entscheidung, die nicht nur das verwendete Shopsystem, sondern auch den weiteren Projektverlauf beeinflussen sollte.
Wie wir darauf reagierten, welche Lösung wir am Ende wählten und welche Learnings wir aus dem Projekt mitnahmen, zeigen wir in diesem Beitrag.
Ausgangslage und Projektziel
Unser Projektpartner war die S&G E-Commerce Solutions OHG, ein junges Unternehmen, das eigene Onlineshops betreibt. Im Mittelpunkt standen der Aufbau und die Optimierung des SOLIT-Shops, über den hochwertige Feuerzeuge angeboten werden.
Junge Onlineshops müssen mehrere Herausforderungen gleichzeitig bewältigen. Die Marke ist noch wenig bekannt, Kundenbewertungen fehlen und es liegen kaum Nutzerdaten vor. Gleichzeitig erwarten Besucher kurze Ladezeiten, eine verständliche Navigation und einen unkomplizierten Bestellprozess.
Wir konzentrierten uns deshalb auf Technik und Nutzererlebnis. Der SOLIT-Shop sollte optisch zur Marke passen, schnell laden und langfristig erweiterbar sein.
Unser Hauptziel war ein funktionsfähiger Headless-Shop mit hoher Performance. Gemessen wurde der Erfolg mit Lighthouse und PageSpeed Insights. Zu Beginn lag die Performance für mobile Geräte bei 79 Punkten und auf dem Desktop bei 85 Punkten. Als Ziel definierten wir mindestens 90 Punkte für mobile Geräte und mindestens 95 Punkte auf dem Desktop. Barrierefreiheit, Best Practices und SEO sollten die vollen 100 Punkte erreichen.
Warum wir auf einen Headless-Shop gesetzt haben
Bei einem klassischen Shopsystem sind Backend und Frontend (Benutzeroberfläche) häufig eng miteinander verbunden. Ein Headless-Ansatz trennt dagegen die beiden Komponenten.
Für SOLIT bot dies mehrere Vorteile. Das Frontend konnte unabhängig von einem Standard-Theme gestaltet und programmiert werden. Dadurch hatten wir mehr Kontrolle über Design, responsive Darstellung und Ladezeiten.
Außerdem sollte das Frontend möglichst unabhängig vom eingesetzten Shopsystem funktionieren. So entstand eine flexible Grundlage für spätere Anpassungen.
Wie wichtig diese Flexibilität werden würde, war uns zu Beginn noch nicht bewusst.
Der E-Commerce Layer als Verbindung
Zwischen Shopsystem und Frontend kam ein E-Commerce Layer zum Einsatz. Der integrierte Data Abstraction Layer bereitete die unterschiedlichen Datenstrukturen des Shopsystems einheitlich auf und stellte sie dem Frontend über eine gleichbleibende Schnittstelle zur Verfügung. Dadurch ließ sich das Shopsystem weitgehend unabhängig vom Frontend austauschen. Zusätzlich unterstützten eine Datenbank und ein Redis-Cache die Verarbeitung und schnelle Bereitstellung der benötigten Daten.
Der E-Commerce Layer wurde primär durch den technischen Ansprechpartner auf Kundenseite entwickelt. Unser Projektteam bereitete parallel das Design vor, programmierte das Frontend und integrierte anschließend die Schnittstelle.
Vom Figma-Entwurf zum Frontend
Vor der Programmierung entwickelten wir das Shopdesign in Figma. Dadurch konnten wir Seitenstruktur und Gestaltung zunächst visuell planen und abstimmen.
Die Designphase vor der Programmierung hatte für uns den entscheidenden Vorteil, dass Farben, Schriften, Bildsprache und die grundsätzliche Anordnung der Inhalte frühzeitig geklärt werden konnten. Dadurch mussten während der Entwicklung weniger grundlegende Designentscheidungen direkt im Code getroffen werden.
Anschließend entwickelten wir das individuelle Frontend. Parallel dazu erstellten wir Produktfotos und Videos für den Onlineshop sowie für unsere Social-Media-Kommunikation.
Im weiteren Verlauf wurde jedoch deutlich, dass sich eine zentrale Annahme unserer technischen Planung nicht wie vorgesehen umsetzen ließ.
Der Wendepunkt: Reicht unser Shopify-Setup aus?
Als Shopsystem war zunächst Shopify vorgesehen. Wir waren davon ausgegangen, dass der gewählte Tarif die API- und Anpassungsfunktionen abdeckt, die wir für unseren Headless-Shop benötigten.
Während der technischen Umsetzung des E-Commerce Layers wurde jedoch klar, dass verschiedene Funktionen im ausgewählten Shopify-Tarif nicht vollständig zur Verfügung standen.
Eine Fortführung mit Shopify wäre möglich gewesen, hätte jedoch einen deutlich teureren Tarif erfordert. Daher musste geprüft werden, ob die höheren laufenden Kosten noch in einem angemessenen Verhältnis zum Nutzen standen.
Während des Projekts trat außerdem eine neue rechtliche Anforderung in Kraft: Ab dem 19. Juni 2026 waren Online-Shops dazu verpflichtet, eine leicht zugängliche elektronische Widerrufsfunktion bereitzustellen.
Für unser damaliges Shopify-Setup stand keine passende native Umsetzung zur Verfügung. Die Funktion hätte über eine zusätzliche App oder individuelle Erweiterung umgesetzt werden müssen. Dadurch wären technische Abhängigkeiten, zusätzlicher Wartungsaufwand und potenziell weitere Kosten entstanden.
Damit mussten wir unsere ursprüngliche Plattformentscheidung neu bewerten.
Wie hätten Sie entschieden?
Wir standen vor zwei Möglichkeiten:
- Shopify mit einem höheren Tarif und zusätzlichen Erweiterungen weiterverwenden.
- Das Shopsystem wechseln und die technische Anbindung anpassen.
Ein Verbleib bei Shopify hätte kurzfristig weniger Umstellungsaufwand bedeutet. Ein Plattformwechsel verursachte zunächst zusätzliche Arbeit, konnte aber langfristige technische und wirtschaftliche Vorteile bieten.
Die Entscheidungsmatrix
Um die Entscheidung nicht ausschließlich nach Bauchgefühl zu treffen, erstellten wir eine gewichtete Entscheidungsmatrix.
Verglichen wurden ein Shopify-Upgrade und ein Wechsel zu Shopware. Die Bewertung erfolgte anhand von sechs Kriterien:
- API- und Funktionsumfang
- Laufende Kosten
- Flexibilität und Erweiterbarkeit
- Rechtliche Umsetzbarkeit
- Kurzfristiger Umsetzungsaufwand
- Langfristige Wartbarkeit
Dem API- und Funktionsumfang gaben wir mit 30 Prozent die höchste Gewichtung. Die laufenden Kosten sowie Flexibilität und Erweiterbarkeit flossen jeweils mit 20 Prozent in die Bewertung ein. Die rechtliche Umsetzbarkeit, der kurzfristige Umsetzungsaufwand und die langfristige Wartbarkeit wurden jeweils mit 10 Prozent gewichtet.
Shopify hatte vor allem beim kurzfristigen Umsetzungsaufwand einen Vorteil. Da wir bereits mit der Plattform gearbeitet hatten, wäre kein vollständiger Wechsel notwendig gewesen.
Shopware überzeugte dagegen stärker beim Funktionsumfang, bei der Flexibilität und bei den laufenden Kosten. Gerade diese Kriterien waren für unseren Kunden und den geplanten Headless-Aufbau besonders wichtig.
In der Gesamtbewertung erreichte das Shopify-Upgrade 3,3 von 5 Punkten. Shopware kam auf 4,4 von 5 Punkten.
Auf dieser Grundlage entschieden wir uns gemeinsam mit dem Kunden für den Wechsel zu Shopware.
Das Projektergebnis – Ein performanter Headless-Shop
Trotz Plattformwechsel hielten wir an unserem Headless-Ansatz fest. Shopware ersetzte Shopify als Shopsystem im Hintergrund. Das individuelle Frontend, die technische Trennung und der E-Commerce Layer blieben zentrale Bestandteile der Architektur.
Für die neue Plattform mussten Schnittstellen und Datenstrukturen aufseiten des Abstraction-Layers angepasst sowie Produkte und Shopfunktionen eingerichtet werden.
Anschließend wurden Frontend, E-Commerce Layer und Shopware verbunden und getestet.
Das Ergebnis ist ein vollständig funktionsfähiger Headless-Shop. Shopware übernimmt die Commerce-Prozesse im Hintergrund, während das individuell programmierte Frontend die Benutzeroberfläche bildet.
Auch unser Performanceziel erreichten wir. Die Performance für mobile Geräte stieg von 79 auf 90 Punkte. Auf dem Desktop verbesserte sich der Wert von 85 auf 98 Punkte.
In den Bereichen Accessibility, Best Practices und SEO erreichten wir sowohl für mobile Geräte als auch auf dem Desktop jeweils die Höchstwertung von 100 Punkten.
Damit wurden unsere Zielwerte übertroffen.
Was wir aus dem Headless-Shop Projekt gelernt haben
Gut funktionierte die parallele Arbeit an Design und Technik, der enge Austausch mit den Inhabern und die Bereitschaft, eine Entscheidung zu hinterfragen.
Gleichzeitig hätten API-Funktionen, Tarifgrenzen und Folgekosten früher geprüft werden müssen. Ein technischer Proof of Concept hätte einige Einschränkungen wahrscheinlich früher sichtbar gemacht.
Auch eine Risikomatrix wäre hilfreich gewesen. Damit hätten wir beispielsweise folgende Risiken frühzeitig erfassen können:
- Steigende Plattformkosten
- Rechtliche Änderungen
- Unerwartete Abhängigkeiten von Drittanbietern
Nach dem ersten Projektfeedback führten wir ein Kanban-Board, eine Roadmap und regelmäßige Abstimmungen ein. Dadurch konnten wir Aufgaben transparenter verteilen und den Projektplan bei größeren Veränderungen anpassen.
Spätestens beim Wechsel des Shopsystems wurde deutlich, dass Projektmanagement besonders dann hilft, wenn ein Projekt nicht wie geplant verläuft.
Fazit Headless-Shop
Unser SOLIT-Projekt zeigt, wie sich ein Headless-Ansatz unter realen Bedingungen umsetzen lässt.
Der Wechsel von Shopify zu Shopware war mit zusätzlichem Aufwand verbunden, führte jedoch zu einer Lösung, die besser zu den technischen und wirtschaftlichen Anforderungen des Kunden passte. Gleichzeitig konnten wir den Headless-Ansatz beibehalten und unsere Performanceziele vollständig erreichen.
Unser wichtigstes Learning lautet, dass eine gute technische Idee allein nicht ausreicht. Funktionen, Kosten, rechtliche Anforderungen, Risiken und Verantwortlichkeiten müssen frühzeitig gemeinsam geprüft werden.
Für zukünftige Projekte würden wir die technische Machbarkeit früher testen, Risiken systematischer erfassen und die Plattformentscheidung stärker an den konkreten Anforderungen ausrichten.