FallstudieSonnenglas: Eine nachhaltige Marke auf 27 Länder skalieren

Als ich im Februar 2024 zum ersten Mal den Quellcode von sonnenglas.net öffnete, hatte der Checkout erhebliche Stabilitätsprobleme. Nutzer konnten Produkte durchstöbern, Artikel in den Warenkorb legen und mussten dann feststellen, dass der Kauffluss scheiterte. Für jeden Online-Shop ist das ein Umsatzproblem. Für ein missionsgetriebenes Sozialunternehmen ist es auch ein Vertrauensproblem.

Die Plattform war seit Jahren mit einer treuen europäischen Kundenbasis aktiv. Aber das technische Fundament hatte seine ursprüngliche Architektur überwachsen. Seiten luden langsam, das CMS kämpfte unter Traffic-Spitzen, und State-Management-Probleme ließen das Einkaufserlebnis unzuverlässig wirken. Währenddessen wollten Kunden aus aller Welt kaufen, und der Shop bediente nur zwei Märkte.

Seit Februar 2024 habe ich die Plattform stabilisiert, Kernsysteme neu aufgebaut und sie von jenen 2 Märkten auf 27 Storefronts in 6 Währungen ausgebaut, ohne geplante Ausfallzeiten. So ist es passiert.

Über Sonnenglas

Sonnenglas ist ein deutsch-südafrikanisches Sozialunternehmen, gegründet 2013. Sie stellen solar-betriebene Einmachglas-Laternen und Lichtkaraffen her, handgeblasene Gefäße aus in Eswatini gesammeltem Recyclingglas. Die Produkte sind wunderschön. Sie haben über 20 internationale Designpreise gewonnen, darunter Red Dot, iF Design und Good Design. Das Sonnenglas Original war das erste Solarlicht, das Deutschlands Blauer-Engel-Zertifizierung erhielt, eines der ältesten und angesehensten Umweltzeichen der Welt.

Aber die eigentliche Geschichte ist nicht das Produkt. Es ist das Geschäftsmodell dahinter.

Ihre Fair-Trade-Fabrik befindet sich in Victoria Yards, Johannesburg. Über 50 Menschen arbeiten dort. 75% der Belegschaft sind Frauen, und alle fünf Abteilungsleiterinnen sind weiblich. 90% der Mitarbeiter kamen aus zuvor arbeitslosen Gemeinschaften. Die Löhne liegen bei mehr als dem Doppelten des lokalen Mindestlohns ohne Gender-Pay-Gap. Alle arbeiten eine 40-Stunden-Woche mit bezuschusster Krankenversicherung. Das Motto ist einfach: "Handel statt Hilfe."

Die Fabrik selbst wird zu 90% durch Solarenergie von 105 Photovoltaik-Modulen auf dem Dach betrieben und erzeugt 40 kW. In einem Viertel, in dem Arbeitslosigkeit die Norm ist, schuf Sonnenglas stabile, würdevolle Arbeit. Die Lichter, die dort gebaut werden, werden von derselben Sonne betrieben, die das Gebäude antreibt, in dem sie hergestellt werden.

Dieser Kontext ist wichtig. Checkout-Zuverlässigkeit ist für jeden Online-Shop wichtig. Für eine Marke, deren Kunden gezielt kaufen, weil sie an die Mission glauben, untergräbt ein schlechtes Einkaufserlebnis das Vertrauen, das das gesamte Modell zum Funktionieren bringt.

Die Plattform als ich einstieg

Als ich die Plattform im Februar 2024 übernahm, war der Checkout das dringendste Problem. Der Cart-State ging während normaler Navigation verloren. Formulareingaben verloren bei Re-Renders ihren Zustand. Der Kaufprozess brach an entscheidenden Stellen ab. Jeder Tag, an dem das so weiterging, gingen Bestellungen unvollständig ab.

Performance war das zweite Problem. Produktbilder hatten zwischen 1 und 7 MB pro Stück, manche Seiten luden bei einem einzigen Aufruf über 20 MB an Assets. Mobile Nutzer mit langsameren Verbindungen hatten eine besonders schlechte Zeit. Seiten, die schnell hätten laden sollen, waren träge und brauchten teilweise mehrere Sekunden, bis sie interaktiv wurden.

Die CMS-Integration stand unter Druck. Die API-Nutzung war weit über nachhaltige Niveaus gewachsen. Bei Traffic-Spitzen gab das System Fehler zurück, die sich in fehlende Content-Blöcke ausbreiteten, genau dann, wenn die meisten Besucher auf der Seite waren.

Re-Rendering-Probleme verschlimmerten alles. Komponenten blinkten auf dem Bildschirm, das Layout verschob sich unvorhersehbar, und interaktive Elemente wie Größenauswähler und Mengenfelder verloren ihren State. Die Plattform hatte ihre ursprüngliche Architektur überwachsen, und die Symptome zeigten sich überall gleichzeitig.

Trotz starker globaler Nachfrage und den 20+ Designpreisen, die internationale Aufmerksamkeit erregten, bediente der Shop nur 2 Märkte. Die Infrastruktur war nicht bereit für eine Expansion. Und durch all das durfte der Shop nicht offline gehen. Der Umsatz musste weiterfließen, während jede Korrektur drum herum ausgeliefert wurde.

Triage und Stabilisierung

Das Erste, was ich behob, war der Checkout. Innerhalb der ersten Wochen war der Kauffluss wieder stabil. Das war das Problem mit dem höchsten Impact mit weitem Abstand, daher kam es als erstes, unabhängig von allem anderen auf der Liste.

Von dort aus kartierte ich die vollständige Kaskade der Probleme. Schlechtes State-Management verursachte unnötige Re-Renders. Diese Re-Renders lösten Hydration-Mismatches zwischen Server und Client aus. Die Hydration-Fehler korrumpierten interaktive Komponenten, einschließlich des Checkouts selbst. Das Beheben von Symptomen würde nicht helfen. Ich musste Ursachen beheben, damit die Probleme nicht wiederkehren.

Ich teilte die Arbeit in zwei Phasen auf. Phase 1: Die Blutungen stoppen. Checkout stabilisieren, die schlimmsten Performance-Probleme beheben, CMS-API-Last auf nachhaltige Niveaus reduzieren und Re-Rendering-Bugs eliminieren. Keine neuen Features. Einfach das Vorhandene zum Laufen bringen. Phase 2: Für Wachstum aufbauen. Multi-Währungs-Support, Marktexpansion, Performance-Optimierung über die Grundlagen hinaus und die Infrastruktur, die zum Skalieren nötig ist.

Jede Änderung wurde inkrementell ausgeliefert. Keine Big-Bang-Deployments, keine Wartungsfenster. Der Shop blieb live und verarbeitete Bestellungen durch den gesamten Prozess. Die Priorisierung erfolgte strikt nach Business-Impact. Wenn eine Korrektur verlorene Umsätze zurückgewinnen oder Bestellausfälle verhindern konnte, kam sie an die Spitze der Queue. Alles andere wartete.

Global gehen

Als ich in das Projekt einstieg, bediente Sonnenglas zwei Regionen. Als die Expansion abgeschlossen war, operierte der Shop auf 27 Storefronts in der EU, Großbritannien, USA, Kanada, der Schweiz und Südafrika und verarbeitete sechs Währungen mit Echtzeit-Preisgestaltung in EUR, GBP, USD, CAD, CHF und ZAR.

Die Komplexität liegt nicht nur darin, Preise in verschiedenen Währungen aufzulisten. Jeder Markt hat seinen eigenen Produktkatalog. Manche SKUs werden nur aus dem deutschen Lager verschickt, andere nur aus Südafrika. Kunden müssen die richtigen Produkte zu den richtigen Preisen mit korrekten Versandursprüngen sehen, und sie sollten ihr Land nicht manuell aus einem Dropdown auswählen müssen, das sie wahrscheinlich ignorieren würden.

Ich baute automatisches Locale-Routing mit Vercels Geolocation-Headern. Wenn ein Besucher aus Toronto auf der Seite landet, sieht er kanadische Dollar, Produkte für den nordamerikanischen Versand und das richtige Ursprungslager. Ein Besucher aus Kapstadt sieht ZAR-Preise und südafrikanisches Inventar. Die Erkennung läuft am Edge, sodass es kein Aufflackern falscher Inhalte oder Währungswechsel nach dem Seitenaufruf gibt.

Jeder Markt benötigte seine eigene Business-Logik über das Routing hinaus. Feiertags-Versandpausen unterscheiden sich zwischen dem deutschen und dem südafrikanischen Lager, jeweils mit unterschiedlichen Stichtagen und Vorlaufzeiten. Gutscheine erforderten währungsbewusstes Routing: Ein EUR-Gutschein, der aus einem USD-Markt gekauft wurde, musste korrekt weitergeleitet werden, damit der Empfänger in seiner lokalen Währung einlösen konnte. Die SKU-Management-Schicht bildet Produktvarianten auf Markt-Verfügbarkeitsregeln ab, sodass wenn Sonnenglas ein Sondereditions-Produkt nur in Europa einführt, der US-Shop es schlicht nicht zeigt. Keine "Ausverkauft"-Meldungen, keine Verwirrung. Das Produkt existiert in diesem Marktkontext nicht.

Das ist das, was einen Shop, der technisch internationale Bestellungen annimmt, von einem unterscheidet, der sich in jedem Land, in dem er tätig ist, lokal anfühlt. Für Sonnenglas bedeutete das, 25 neue Märkte zu eröffnen, ohne Support-Tickets zu vervielfachen oder ein dediziertes Lokalisierungsteam zu benötigen.

Die Commerce Engine neu aufbauen

Die Plattform benötigte eine Produktdatenarchitektur, die sowohl transaktionale Genauigkeit als auch redaktionell reiche Inhalte verarbeiten kann. Ich baute ein Dual-Source-System. Inventar, Preise und Variantendaten kommen von der Backend-REST-API, der Source of Truth für alles Transaktionale. Redaktionelle Inhalte, Mediengalerien, Feature-Beschreibungen und Cross-Sell-Beziehungen kommen von Hygraphs GraphQL-CMS. Auf der Anwendungsebene führt ein Anreicherungsmuster diese beiden Quellen zusammen: Die App holt Basis-Produktdaten von REST und reichert dann jedes Produkt mit dem entsprechenden CMS-Inhalt an, bevor sie es rendert.

Das gibt dem Content-Team volle kreative Kontrolle, ohne das Backend anzufassen, während Preise und Lagerbestände aktuell bleiben. Neue Produkte wie die Lichtkaraffe 2025 und SOMO Gen6 fließen durch dieselbe Pipeline, von der Landingpage über den Checkout bis zum Fulfillment.

Das virtuelle Produktsystem erweitert dieses Muster für Gutscheine und digitale Artikel. Diese Produkte existieren nur im CMS als Elterneinträge, ohne physisches Produkt im Backend dahinter. Das System aggregiert automatisch verfügbare Denominationen und Varianten aus den Gutscheindaten des Backends und präsentiert sie unter dem CMS-verwalteten Elternelement. Das Marketing-Team gestaltet das Gutschein-Erlebnis, schreibt die Texte und wählt die Bilder. Das eigentliche Finanzinstrument bleibt im Backend, wo es hingehört.

Bundles und Sets funktionieren ähnlich. Das Content-Team kann Produkt-Bundles vollständig durch das CMS erstellen, mit Variantenauswahl, dynamischer Preisgestaltung und Verfügbarkeitsanzeigen, die alle durch dieselbe Dual-Source-Architektur gesteuert werden. Einzelne Produkte können auch als Bundle-Einträge dienen, sodass das System flexibel genug ist, um mit allem umzugehen, was das Marketing-Team zusammenstellt.

Das Partial-Delivery-System war das größte Feature, das ich für die Plattform gebaut habe. Sonnenglas führt regelmäßig Vorbestellungs-Kampagnen neben Produkten auf Lager durch. Bevor dieses System existierte, musste ein Kunde, der ein lagerndes Glas und ein vorbestelltes Glas zusammen bestellt, wochenlang auf die gesamte Bestellung warten. Das System teilt jetzt gemischte Bestellungen intelligent in Versandgruppen auf: Lagerartikel werden sofort versandt, Vorbestellungsartikel wenn verfügbar. Jede Gruppe bekommt ihre eigene Versandberechnung mit unabhängigen Gratisversand-Schwellenwerten.

Das erforderte ein Umdenken des gesamten Warenkorb- und Checkout-Flusses. Line-Items tragen Metadaten über ihre Fulfillment-Gruppe. Versandkosten werden pro Gruppe berechnet. Die Checkout-Übersicht zeigt Kunden genau, was wann versendet wird, mit separaten Lieferschätzungen. Stripe verarbeitet die einzelne Zahlung, aber die Fulfillment-Pipeline verarbeitet jede Gruppe auf ihrer eigenen Zeitlinie.

Gutschein- und Rabattcodes werden beim Checkout mit Echtzeit-Validierung angewendet, und die Vergleichspreis-Anzeige zeigt Kunden, was sie sparen.

Das Produktbewertungssystem unterstützt Suche, Sortierung und Seitennavigation über tausende von Bewertungen in Englisch und Deutsch. Produktbildkarussells sind auf Mobilgeräten wischbar mit Pinch-to-Zoom, und das Variantenwechseln behält die Scroll-Position bei, sodass Kunden nie ihren Platz auf der Seite verlieren.

Performance und Infrastruktur

Der originale Codebase verwendete React Context für den globalen State. Cart-State, Locale-Präferenzen, UI-Flags und Kundendaten lebten alle in verschachtelten Context-Providern, die bei jeder Aktualisierung vollständige Tree-Re-Renders auslösten. Ich migrierte das State-Management auf Zustand für synchronen Client-State und TanStack React Query für Server-State mit Persistenz. Warenkorb-Updates erfolgten sofort. Navigation zwischen Seiten hörte auf, träge zu wirken. Optimistische Updates bedeuten, dass die UI reagiert, bevor der Server bestätigt, sodass das Hinzufügen eines Artikels in den Warenkorb unmittelbar wirkt.

Die CMS-API-Nutzung war weit über dem zugewiesenen Kontingent, mit redundanten Anfragen bei jedem Seiten-Rendering. Dieselben Produktdaten wurden mehrfach pro Seite abgerufen. Bei diesem Tempo riskierte der Shop Fehler bei Traffic-Spitzen und erhebliche Überschreitungsgebühren.

Die Lösung war ein mehrschichtiger Ansatz auf der Datenabruf-Ebene. Ein DataLoader-Pattern bündelt gleichzeitige Anfragen für denselben Ressourcentyp in einzelne API-Aufrufe. Rate-Limiting begrenzt ausgehende Anfragen knapp unter dem API-Schwellenwert. Request-Deduplication stellt sicher, dass wenn mehrere Komponenten dieselben Daten benötigen, nur eine Anfrage abgesendet wird. In-Memory-Caching mit Webhook-basierter Invalidierung bedeutet, dass nachfolgende Anfragen für unveränderte Inhalte die API überhaupt nicht treffen. Zusammen brachten diese Änderungen die Nutzung gut innerhalb des Kontingents, ohne die Datenfrische zu opfern.

Bildoptimierung reduzierte die Payload pro Seite dramatisch. Produktseiten, die zuvor 1 bis 7 MB unkomprimierte Bilder luden, liefern jetzt responsive WebP- und AVIF-Formate in angemessenen Abmessungen. Mux verarbeitet die Video-Optimierung. Hydration-Fehler wurden im gesamten Codebase eliminiert und Layout-Shifts durchgehend behoben, was die Core-Web-Vitals-Scores verbesserte.

Für SEO erhält jede der 27 Marktvarianten korrekte hreflang-Tags, damit Google die richtige Locale in den Suchergebnissen ausliefert. Produktseiten beinhalten JSON-LD-Strukturdaten für Rich Snippets mit korrekten Varianten-URLs und kanonischer Behandlung. Automatisierte Sitemaps werden bei Content-Änderungen mit Ausschluss virtueller Produkte neu generiert. Ein Google-Merchant-Center-Feed-Generator exportiert den vollständigen Katalog mit marktspezifischen Preisen für Shopping-Anzeigen.

Der gesamte Codebase wurde zu TypeScript migriert und gibt jeder Komponente, jedem Hook und jeder Utility-Funktion ordentliche Typsicherheit. CI/CD führt Type-Checking bei jedem Pull Request durch GitHub Actions Workflows durch. Das Build-System wechselte von Webpack zu Turbopack für schnellere Entwicklungszyklen, und ich optimierte die statische Generierung, indem ich die Anzahl der vorab gerenderten Locale-Pfade reduzierte, um die Build-Zeiten bei wachsender Marktanzahl handhabbar zu halten.

Monitoring, Previews und CMS-Architektur

Das Produktions-Monitoring läuft durch Axiom mit Echtzeit-Einblick in Fehler, API-Antwortzeiten und Edge-Function-Performance. Kaufdaten werden separat protokolliert, sodass Checkout-Fehler automatische Alarme auslösen. Web-Vitals-Tracking fließt in das Performance-Monitoring ein und macht Regressionen sichtbar, bevor sie zu Kundenproblemen werden.

Das Hygraph-Live-Preview-System lässt Content-Editoren ihre Änderungen in Echtzeit sehen, bevor sie veröffentlichen. Ich baute es mit Error-Boundaries, die nützliche Informationen anzeigen, wenn erforderliche Felder fehlen oder Content-Strukturen unvollständig sind. Anstatt dass die Vorschau stillschweigend abbricht, sehen Editoren genau, welches Feld Aufmerksamkeit benötigt. Das reduzierte den Hin-und-Her-Austausch zwischen dem Content-Team und der Entwicklung erheblich.

Auf der CMS-Architektur-Seite entwickelte ich umfangreiche Hygraph-Schemas für Produkte, Seiten, Navigation, Footer-Inhalte, globale Konfiguration und Ankündigungs-Banner. Das Revalidierungssystem verwendet Webhooks, um spezifische Pfade bei Content-Änderungen zu invalidieren, mit locale-bewusster Pfadgenerierung und einem vollständigen Layout-Revalidierungs-Trigger für Meta-Änderungen wie Navigation und Footer-Updates. Content-Editoren können Updates veröffentlichen und sie innerhalb von Sekunden auf der Live-Site sehen.

Ergebnisse

Stabilisierung

Der Checkout wurde in den ersten Wochen behoben. Der Fluss, der Verkäufe verlor, funktioniert jetzt zuverlässig auf allen Storefronts und Geräten. Der Cart-State bleibt während der Navigation erhalten, Formularfelder behalten ihre Werte, und Zahlungen werden korrekt verarbeitet.

Die API-Nutzung sank von weit über dem Kontingent auf gesunde, vorhersehbare Niveaus durch die Batching-, Caching- und Rate-Limiting-Infrastruktur. Das CMS verarbeitet Traffic-Spitzen ohne Fehler. Seiten, die früher während Stoßzeiten abbrachen, liefern jetzt Content konsistent.

Produktseiten gingen vom Laden von Megabytes unkomprimierter Assets zur Bereitstellung von responsiven, korrekt dimensionierten Bildern über. Hydration-Fehler und die Re-Rendering-Loops, die sie verursachten, wurden auf Ursachen zurückverfolgt und systematisch eliminiert.

All das geschah ohne geplante Ausfallzeiten. Der Shop verkaufte weiter durch jedes Deployment und jede Migration.

Wachstum

Die Plattform expandierte von 2 Ländern auf 27. Sechs Währungen mit Echtzeit-Preisgestaltung. Automatisches Geo-IP-Routing, das Besucher ohne Nachfragen in ihren korrekten Markt bringt. Über 25 große Features wurden in die Produktion ausgeliefert, vom Partial-Delivery-System, das Support-Tickets reduzierte, bis zu Google-Shopping-Feeds, die automatisch über alle Märkte laufen.

Das Marketing-Team gewann volle Eigenverantwortung durch das CMS. Sie starten Kampagnen, aktualisieren locale-spezifische Ankündigungs-Banner, verwalten saisonale Promotions und veröffentlichen Content-Änderungen, die kurz danach live gehen. Neue Produktlaunches wie die Lichtkaraffe 2025 und SOMO Gen6 laufen vollständig durch die Plattform, von der Landingpage über den Checkout bis zum Fulfillment, ohne Entwickler-Beteiligung für Inhalte. Das Garantieformular, die Seriennummern-Validierung und der mehrsprachige Formular-Support fließen alle in dasselbe Self-Service-Modell ein.

Eine laufende Partnerschaft

Ich begann im Februar 2024 mit Sonnenglas zu arbeiten. Die Zusammenarbeit läuft als laufende Produktpartnerschaft weiter. Das ist kein projektbasiertes Engagement, bei dem ich einen Scope liefere und gehe.

Das bedeutet, Weihnachts-Versandlogik zu bauen, wenn das Feiertagsgeschäft naht, Oster-Promotionsmechaniken im Frühling einzurichten und dafür zu sorgen, dass neue Produktlaunches wie die Lichtkaraffe 2025 alles haben, was sie auf der technischen Seite brauchen. Die Plattform ist kein fertiges Produkt. Sie entwickelt sich mit dem Unternehmen, und ich entwickle mich mit ihr.

Was diese Arbeit möglich macht, ist Vertrauen, das über Zeit aufgebaut wurde. Das Team weiß, dass ich ihren Stack, ihre Kunden und ihre Einschränkungen verstehe. Ich weiß, dass sie die Plattform in Richtungen treiben werden, die die Dinge interessant halten. Gute Partnerschaften sind selten, und ich nehme diese nicht als selbstverständlich.

Jede optimierte Seite, jeder wiederhergestellte Checkout, jeder neu erschlossene Markt hilft einer Marke, die wirklich einen Unterschied macht, mehr Menschen zu erreichen. Das ist es wert, dafür zu bauen.