FallstudieVon defekten Checkouts zu 27 Ländern: Sonnenglas' globale Plattform

Als ich im Februar 2024 zum ersten Mal den Quellcode von sonnenglas.net öffnete, war der Checkout defekt. Nicht theoretisch defekt, nicht "hat manchmal Probleme" defekt. Nutzer konnten zu einem Produkt navigieren, es in den Warenkorb legen und dann dabei zusehen, wie der Checkout scheiterte. Für jedes E-Commerce-Unternehmen ist das ein ernstes Problem. Für ein Sozialunternehmen, dessen Marke auf Vertrauen und einem klaren Zweck aufgebaut ist, beeinflusst das die Wahrnehmung jedes einzelnen Besuchers.

Der Shop war seit Jahren aktiv und hatte eine treue Kundenbasis in ganz Europa. Aber das technische Fundament bröckelte. Seiten luden langsam, das CMS brach unter dem Traffic ein, und der Checkout-Fluss hatte State-Management-Probleme, die den Abschluss eines Kaufs wie ein Münzwurf erscheinen ließen. Das ist eine Situation, die sich keine wachsende Marke leisten kann.

24 Monate später bedient die Plattform 27 Länder in 6 Währungen ohne Ausfallzeiten. Das ist die Geschichte, wie wir dorthin gekommen sind.

Über Sonnenglas

Sonnenglas ist ein deutsch-südafrikanisches Sozialunternehmen, gegründet 2013. Sie stellen solar-betriebene Einmachglas-Lichter und Lichtkaraffen her, handgeblasene Gefäße aus in Eswatini gesammeltem Recyclingglas. Die Produkte sind wunderschön, aber die eigentliche Geschichte steckt im Geschäftsmodell dahinter.

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

Die Fabrik selbst wird zu 90% durch Solarenergie von 105 PV-Modulen auf dem Dach betrieben. Das Sonnenglas Original war das erste Solarlicht, das Deutschlands Blauer-Engel-Zertifizierung erhielt, eines der ältesten und angesehensten Umweltzeichen der Welt. Die Produkte haben über 20 Designpreise gewonnen, darunter Red Dot, iF Design und Good Design.

Das ist wichtiger Kontext. Wenn der Checkout bei einem typischen E-Commerce-Shop abbricht, verliert ein Unternehmen Geld. Wenn er bei sonnenglas.net abbricht, trifft das eine Marke, deren gesamte Identität darauf aufgebaut ist, die Dinge richtig zu machen. Ein kaputtes Einkaufserlebnis untergräbt das Vertrauen, das Kunden in ein Sozialunternehmen setzen. Die technischen Probleme waren nicht nur technische Probleme.

Die Situation als ich einstieg

Als ich die Plattform im Februar 2024 übernahm, war das dringendste Problem der Checkout. Nutzer konnten Produkte problemlos durchstöbern, aber der Kauffluss brach bei normaler Navigation zusammen. Der Cart-State ging verloren, Formulareingaben verloren bei Re-Renders ihren Zustand, und der Kaufprozess brach an entscheidenden Stellen ab. Jeder Tag, an dem das so weiterging, bedeutete Bestellungen, die nie abgeschlossen wurden.

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

Die CMS-Integration war fragil. Die API-Nutzung war weit über nachhaltige Niveaus gewachsen. Bei Traffic-Spitzen begann das CMS, Fehler zurückzugeben, die sich in kaputte Produktseiten und fehlende Content-Blöcke ausbreiteten, genau dann, wenn die meisten Besucher auf der Seite waren.

Re-Rendering-Probleme verursachten visuelle Störungen im gesamten Storefront. Komponenten flackerten, das Layout sprang, und interaktive Elemente wie Größenauswähler und Mengenfelder verloren ihren State. Das ließ die gesamte Erfahrung unzuverlässig wirken.

Trotz starker Nachfrage von Kunden weltweit bediente der Shop nur 2 Märkte. Die Infrastruktur war nicht bereit für eine Expansion. Und die harte Bedingung durch all das: Der Shop durfte nicht offline gehen. Der Umsatz musste weiterfließen, während jede Korrektur drum herum ausgeliefert wurde.

Strategie: Triage, Stabilisieren, Aufbauen

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. Das Beheben der Ursache bedeutete, dass die Symptome nicht wiederkehren würden.

Ich teilte die Arbeit in zwei Phasen auf. Phase 1 drehte sich um das Stoppen der Blutungen: Checkout stabilisieren, die schlimmsten Performance-Probleme beheben, CMS-API-Last auf nachhaltige Niveaus reduzieren und Re-Rendering-Bugs eliminieren, die das Nutzererlebnis beeinträchtigten. Keine neuen Features, nur das Vorhandene zum Laufen bringen.

Phase 2 drehte sich um den Aufbau für Wachstum: Multi-Währungs-Support, Expansion in neue Märkte, Performance-Optimierung über die Grundlagen hinaus und die Infrastrukturarbeit, die nötig war, um von 2 Ländern auf 27 zu skalieren.

Jede Änderung wurde inkrementell ausgeliefert. Keine Big-Bang-Deployments, keine Wartungsfenster. Der Shop blieb während des gesamten Prozesses live und verarbeitete Bestellungen. 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.

Was folgt, ist ein detaillierter Blick auf das, was in diesen 24 Monaten aufgebaut wurde.

Global gehen: 27 Länder, 6 Währungen

Als ich in das Projekt einstieg, bediente Sonnenglas zwei Regionen. Als die Expansion abgeschlossen war, operierte der Shop in 27 Ländern 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, ohne ihr Land manuell aus einem Dropdown auswählen zu 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.

Über das einfache Routing hinaus benötigte jeder Markt seine eigene Business-Logik. 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-Kauf aus einem USD-Markt 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. Wenn Sonnenglas ein Sondereditions-Produkt nur in Europa einführt, zeigt der US-Shop es schlicht nicht an. Keine "Ausverkauft"-Meldungen, keine Verwirrung. Das Produkt existiert in diesem Marktkontext nicht.

Diese Art von Multi-Markt-Infrastruktur 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.

Die Commerce Engine neu aufbauen

Die Plattform benötigte eine Produktdatenarchitektur, die sowohl transaktionale Genauigkeit als auch redaktionell reiche Inhalte verarbeiten kann.

Ich baute eine Dual-Source-Produktarchitektur. 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 sekundengenau aktuell bleiben.

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 bedeutet, das Marketing-Team kann das Gutschein-Erlebnis gestalten, die Texte schreiben und die Bilder auswählen, während das eigentliche Finanzinstrument im Backend bleibt, wo es hingehört.

Das Partial-Delivery-System löste einen realen operativen Schmerzpunkt. Sonnenglas führt regelmäßig Vorbestellungs-Kampagnen neben Produkten auf Lager durch. Bevor ich das gebaut habe, 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.

Das Produktbewertungssystem unterstützt Suche, Sortierung und Seitennavigation über tausende von Bewertungen hinweg mit automatischer Übersetzung zwischen Englisch und Deutsch. Produktkarussells verwenden physikbasiertes Embla Carousel mit Touch, Swipe und Pinch-to-Zoom auf Mobilgeräten. Gutschein- und Rabattcodes werden beim Checkout mit Echtzeit-Validierung gegen die Rabattregeln des Backends angewendet.

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. Warenkorb-Updates erfolgten sofort. Navigation zwischen Seiten hörte auf, träge zu wirken.

Die CMS-Optimierungsgeschichte verdient einen eigenen Absatz. Als ich die Hygraph-API-Nutzung auditierte, lag das Projekt weit über einem nachhaltigen Niveau. Jedes Seiten-Rendering löste redundante Anfragen aus. Dieselben Produktdaten wurden mehrfach pro Seite abgerufen. Bei diesem Tempo riskierte der Shop API-Fehler bei Traffic-Spitzen und erhebliche Überschreitungsgebühren.

Mein erster Versuch verwendete Vercel KV als Rate-Limiting-Schicht, Caching von Antworten und Drosselung ausgehender Anfragen. Es funktionierte in der Entwicklung, brach aber Server-Side-Rendering in der Produktion. KV-Reads fügten genug Latenz hinzu, um SSR-Antwortzeiten über akzeptable Schwellenwerte zu drücken, und das Cold-Start-Verhalten war unvorhersehbar. Ich verwarf es.

Die Lösung, die funktionierte, war ein mehrschichtiger Ansatz direkt auf der Datenabruf-Ebene. Ein DataLoader-Pattern bündelt gleichzeitige Anfragen für denselben Ressourcentyp in einzelne API-Aufrufe. p-throttle begrenzt ausgehende Anfragen auf 15 pro Sekunde, knapp unter dem API-Limit. Request-Deduplication stellt sicher, dass wenn drei Komponenten auf derselben Seite dieselben Produktdaten 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 API-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 PNGs und JPGs luden, liefern jetzt responsive WebP- und AVIF-Formate in angemessenen Abmessungen. Ich eliminierte Hydration-Fehler im gesamten Codebase und behob Layout-Shifts, die die Core-Web-Vitals-Scores beeinträchtigten.

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. Automatisierte Sitemaps werden bei Content-Änderungen 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. CI/CD führt Type-Checking und Linting bei jedem Pull Request durch. Produktions-Monitoring durch Axiom bietet Echtzeit-Einblick in Fehler, API-Antwortzeiten und Edge-Function-Performance.

Ergebnisse

Als ich in das Projekt einstieg, war der Checkout defekt. Kunden in mehreren Märkten trafen auf Fehler, abgebrochene Warenkörbe stiegen, und das Team hatte keinen klaren Weg, es zu beheben. Das war das Erste, was ich anging, und innerhalb von Wochen war der Checkout vollständig wiederhergestellt. Er funktioniert jetzt zuverlässig in allen 27 Märkten, auf allen Geräten, mit jeder Zahlungsmethode. Keine verlorenen Bestellungen mehr.

Stabilisierung

Die API-Schicht war das Nächste. Die Rate-Limits der Hygraph-API wurden ständig erreicht, weil jeder Seitenaufruf dutzende von unoptimisierten Calls auslöste. Ich führte Request-Batching, Response-Caching und ordentliches Rate-Limit-Handling ein. Die API-Nutzung sank von nicht nachhaltigen Niveaus auf gesunde, vorhersehbare Muster.

Performance folgte. Produktbilder, die mit 1-7 MB pro Datei ausgeliefert wurden, wurden durch optimierte, responsive Formate ersetzt. Seiten, die Sekunden brauchten, um interaktiv zu werden, laden jetzt schnell. Die Hydration-Fehler, die UI-Störungen und Re-Rendering-Loops verursachten, wurden auf ihre Ursachen zurückverfolgt und einzeln eliminiert.

All das geschah ohne Ausfallzeiten. Der Shop verkaufte weiter durch jedes Deployment, jede Migration, jedes Refactoring.

Wachstum

Mit einem stabilen Fundament konnten wir aufbauen. Die Plattform expandierte von 2 Ländern auf 27, eine 13,5-fache Marktexpansion. Sechs Währungen mit Echtzeit-Preisgestaltung. Über 25 große Features wurden ausgeliefert, von Google-Shopping-Feeds, die automatisch über alle Märkte laufen, bis hin zu einem Partial-Delivery-System, das Kunden-Support-Tickets reduzierte.

Das Marketing-Team gewann volle Eigenverantwortung durch das CMS. Sie starten Kampagnen, aktualisieren Inhalte und verwalten Promotions ohne Entwickler-Beteiligung. Neue Produkte wie die Lichtkaraffe 2025 und SOMO Gen6 laufen über dieselbe Plattform, von der Landingpage über den Checkout bis zum Fulfillment.

Eine laufende Partnerschaft

Ich begann im Februar 2024 mit Sonnenglas zu arbeiten. Über 24 Monate später läuft die Zusammenarbeit noch. Das ist keine Auftragnehmer-Beziehung, bei der ich einen Scope liefere und verschwinde. Ich bin in den Workflow des Teams eingebettet, Teil des täglichen Rhythmus des Auf- und Ausbaus der Plattform.

Das bedeutet, Weihnachts-Versandlogik zu unterstützen, wenn das Feiertagsgeschäft naht, Oster-Promotionsmechaniken im Frühling zu bauen und dafür zu sorgen, dass neue Produktlaunches 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.

Sonnenglas ist der Beweis, dass Technologie, richtig eingesetzt, die Mission einer Marke verstärken kann. Jede optimierte Seite, jeder wiederhergestellte Checkout, jeder neu erschlossene Markt bedeutet mehr Solarlampen in mehr Händen und mehr Fair-Trade-Jobs in Johannesburg.