Case StudySonnenglas: Scaling a Sustainable Brand to 27 Countries

When I first opened the codebase for sonnenglas.net in February 2024, the checkout had significant stability issues. Users could browse products, add items to their cart, and then find the purchase flow failing. For any online store, that is a revenue problem. For a mission-driven social enterprise, it is also a trust problem.

The platform had been live for years with a loyal European customer base. But the technical foundation had outgrown its original architecture. Pages loaded slowly, the CMS struggled under traffic spikes, and state management issues made the shopping experience feel unreliable. Meanwhile, customers from around the world wanted to buy, and the store only served two markets.

Since February 2024, I have stabilized the platform, rebuilt core systems, and expanded it from those 2 markets to 27 storefronts across 6 currencies, without scheduled downtime. This is how it happened.

About Sonnenglas

Sonnenglas is a German-South African social enterprise founded in 2013. They make solar-powered mason jar lanterns and Lichtkaraffen, handblown vessels crafted from recycled glass collected in Eswatini. The products are beautiful. They have won over 20 international design awards, including Red Dot, iF Design, and Good Design. The Sonnenglas Original was the first solar light to earn Germany's Blauer Engel certification, one of the oldest and most respected environmental labels in the world.

But the real story is not the product. It is the business model behind it.

Their Fair Trade factory sits in Victoria Yards, Johannesburg. Over 50 people work there. 75% of the workforce are women, and all five department heads are female. 90% of employees came from previously unemployed communities. Wages run at more than double the local minimum with no gender pay gap. Everyone works a 40-hour week with subsidized health insurance. The motto is simple: "Trade instead of Aid."

The factory itself runs on 90% solar power from 105 photovoltaic panels on the roof, generating 40 kW. In a neighborhood where unemployment is the norm, Sonnenglas created stable, dignified work. The lights they build are powered by the same sun that powers the building where they are made.

This context matters. Checkout reliability is important for any online store. For a brand whose customers buy specifically because they believe in the mission, a poor shopping experience undermines the trust that makes the whole model work.

The Platform When I Joined

When I took over the platform in February 2024, the checkout was the most urgent issue. Cart state got lost during normal navigation. Form inputs lost their state during re-renders. The purchase flow broke at critical steps. Every day this continued, orders went uncompleted.

Performance was the second problem. Product images ranged from 1 to 7 MB each, with some pages pulling down over 20 MB of assets on a single load. Mobile users on slower connections had a particularly rough time. Pages that should have loaded quickly were sluggish, with some taking several seconds to become interactive.

The CMS integration was under pressure. API usage had grown well beyond sustainable levels. During peak traffic, the system would return errors that cascaded into missing content blocks right when the most visitors were on the site.

Re-rendering issues compounded everything. Components flashed on screen, layout shifted unpredictably, and interactive elements like size selectors and quantity inputs lost their state. The platform had outgrown its original architecture, and the symptoms showed up everywhere at once.

Despite strong global demand and those 20+ design awards drawing international attention, the store served only 2 markets. The infrastructure was not ready to expand. And through all of this, the store could not go offline. Revenue had to keep flowing while every fix shipped around it.

Triage and Stabilization

The first thing I fixed was the checkout. Within the first few weeks, the purchase flow was stable again. This was the highest-impact problem by a wide margin, so it came first regardless of what else was on the list.

From there, I mapped the full cascade of issues. Bad state management caused unnecessary re-renders. Those re-renders triggered hydration mismatches between server and client. The hydration errors corrupted interactive components, including the checkout itself. Fixing symptoms would not help. I needed to fix root causes so the problems stopped coming back.

I split the work into two phases. Phase 1: stop the bleeding. Stabilize checkout, fix the worst performance issues, reduce CMS API load to sustainable levels, and eliminate re-rendering bugs. No new features. Just making what existed actually work. Phase 2: build for growth. Multi-currency support, market expansion, performance optimization beyond the basics, and the infrastructure needed to scale.

Every change shipped incrementally. No big-bang deployments, no maintenance windows. The store stayed live, processing orders through the entire process. Prioritization was strictly by business impact. If a fix could recover lost revenue or prevent order failures, it went to the top of the queue. Everything else waited.

Going Global

When I joined the project, Sonnenglas served two regions. By the time the expansion was complete, the store operated across 27 storefronts covering the EU, UK, USA, Canada, Switzerland, and South Africa, handling six currencies with real-time pricing in EUR, GBP, USD, CAD, CHF, and ZAR.

The complexity is not just in listing prices in different currencies. Each market has its own product catalog. Some SKUs ship only from the German warehouse, others only from South Africa. Customers need to see the right products at the right prices with accurate shipping origins, and they should not have to manually select their country from a dropdown they will probably ignore.

I built automatic locale routing using Vercel's geolocation headers. When a visitor from Toronto lands on the site, they see Canadian dollars, products available for North American shipping, and the correct origin warehouse. A visitor from Cape Town sees ZAR pricing and South African inventory. The detection runs at the edge, so there is no flash of wrong content or currency switching after page load.

Each market needed its own business logic beyond routing. Holiday shipping breaks differ between the German and South African warehouses, each with different cutoff dates and lead times. Gift cards required currency-aware routing: a EUR gift card purchased from a USD market needed to redirect correctly so the recipient could redeem in their local currency. The SKU management layer maps product variants to market availability rules, so when Sonnenglas launches a limited edition product in Europe only, the US store simply does not show it. No "out of stock" messages, no confusion. The product does not exist in that market context.

This is what separates a store that technically accepts international orders from one that feels local in every country it serves. For Sonnenglas, it meant opening 25 new markets without multiplying support tickets or requiring a dedicated localization team.

Rebuilding the Commerce Engine

The platform needed a product data architecture that could handle both transactional accuracy and rich editorial content. I built a dual-source system. Inventory, pricing, and variant data come from the backend REST API, the source of truth for anything transactional. Editorial content, media galleries, feature descriptions, and cross-sell relationships come from Hygraph's GraphQL CMS. At the application layer, an enrichment pattern merges these two sources: the app fetches base product data from REST, then enriches each product with its corresponding CMS content before rendering.

This gives the content team full creative control without touching the backend, while pricing and stock levels stay current. New products like the Lichtkaraffe 2025 and SOMO Gen6 flow through the same pipeline, from landing page to checkout to fulfillment.

The virtual product system extends this pattern for gift cards and digital items. These products exist only in the CMS as parent entries, with no physical product in the backend behind them. The system automatically aggregates available denominations and variants from the backend's gift card data and presents them under the CMS-managed parent. The marketing team designs the gift card experience, writes the copy, and chooses the imagery. The actual financial instrument stays in the backend where it belongs.

Bundles and sets work similarly. The content team can create product bundles entirely through the CMS, with variant selection, dynamic pricing, and availability indicators all driven by the same dual-source architecture. Single products can also serve as bundle entries, so the system is flexible enough to handle whatever the marketing team puts together.

The partial delivery system was the largest feature I built for the platform. Sonnenglas regularly runs preorder campaigns alongside in-stock products. Before this system existed, a customer ordering one in-stock jar and one preorder jar would wait weeks for the entire order. The system now intelligently splits mixed orders into shipment groups: in-stock items ship immediately, preorder items ship when available. Each group gets its own shipping calculation with independent free shipping thresholds.

This required rethinking the entire cart and checkout flow. Line items carry metadata about their fulfillment group. Shipping rates calculate per group. The checkout summary shows customers exactly what ships when, with separate delivery estimates. Stripe handles the single payment, but the fulfillment pipeline processes each group on its own timeline.

Voucher and discount codes apply at checkout with real-time validation, and compare-at-price display shows customers what they are saving.

The product review system supports search, sorting, and pagination across thousands of reviews in both English and German. Product image carousels are swipeable on mobile with pinch-to-zoom, and variant switching maintains scroll position so customers never lose their place on the page.

Performance and Infrastructure

The original codebase used React Context for global state. Cart state, locale preferences, UI flags, and customer data all lived in nested context providers that triggered full tree re-renders on every update. I migrated state management to Zustand for synchronous client state and TanStack React Query for server state with persistence. Cart updates became instant. Navigation between pages stopped feeling sluggish. Optimistic updates mean the UI responds before the server confirms, so adding an item to the cart feels immediate.

CMS API usage was well beyond the allocated quota, with redundant requests fired on every page render. The same product data was fetched multiple times per page. At that rate, the store risked errors during traffic spikes and significant overage charges.

The fix was a multi-layered approach at the data-fetching level. A DataLoader pattern batches concurrent requests for the same resource type into single API calls. Rate limiting caps outbound requests just under the API threshold. Request deduplication ensures that if multiple components need the same data, only one request fires. In-memory caching with webhook-based invalidation means subsequent requests for unchanged content never hit the API at all. Combined, these changes brought usage well within quota without sacrificing data freshness.

Image optimization cut per-page payload dramatically. Product pages that previously loaded 1 to 7 MB of unoptimized images now serve responsive WebP and AVIF formats at appropriate dimensions. Mux handles video optimization. Hydration errors were eliminated across the codebase and layout shifts fixed throughout, improving Core Web Vitals scores.

For SEO, each of the 27 market variants gets proper hreflang tags so Google serves the right locale in search results. Product pages include JSON-LD structured data for rich snippets with correct variant URLs and canonical handling. Automated sitemaps regenerate on content changes with virtual product exclusion. A Google Merchant Center feed generator exports the full catalog with market-specific pricing for Shopping ads.

The entire codebase was migrated to TypeScript, giving every component, hook, and utility function proper type safety. CI/CD runs type checking on every pull request through GitHub Actions workflows. The build system moved from Webpack to Turbopack for faster development cycles, and I optimized static generation by reducing the number of pre-rendered locale paths to keep build times manageable as the market count grew.

Monitoring, Previews, and CMS Architecture

Production monitoring runs through Axiom with real-time visibility into errors, API response times, and edge function performance. Purchase data gets logged separately, so checkout failures trigger automatic alerts. Web vitals tracking feeds into performance monitoring, making regressions visible before they become customer-facing problems.

The Hygraph live preview system lets content editors see their changes in real time before publishing. I built this with error boundaries that display useful information when required fields are missing or content structures are incomplete. Instead of the preview silently breaking, editors see exactly which field needs attention. This reduced the back-and-forth between the content team and development significantly.

On the CMS architecture side, I developed extensive Hygraph schemas for products, pages, navigation, footer content, global configuration, and announcement banners. The revalidation system uses webhooks to invalidate specific paths when content changes, with locale-aware path generation and a full layout revalidation trigger for meta changes like navigation and footer updates. Content editors can publish updates and see them reflected on the live site within seconds.

Results

Stabilization

The checkout was fixed in the first weeks. The flow that had been losing sales now works reliably across all storefronts and devices. Cart state persists through navigation, form fields hold their values, and payments process correctly.

API usage dropped from well over quota to healthy, predictable levels through the batching, caching, and rate-limiting infrastructure. The CMS handles traffic spikes without errors. Pages that used to break during peak hours now serve content consistently.

Product pages went from loading megabytes of unoptimized assets to serving responsive, properly sized images. Hydration errors and the re-rendering loops they caused were traced to root causes and eliminated systematically.

All of this happened without scheduled downtime. The store kept selling through every deployment and migration.

Growth

The platform expanded from 2 countries to 27. Six currencies with real-time pricing. Automatic geo-IP routing that puts visitors in their correct market without asking. Over 25 major features shipped to production, from the partial delivery system that reduced support tickets to Google Shopping feeds that run automatically across all markets.

The marketing team gained full self-service through the CMS. They launch campaigns, update locale-specific announcement banners, manage seasonal promotions, and publish content changes that go live shortly after. New product launches like the Lichtkaraffe 2025 and SOMO Gen6 run entirely through the platform, from landing page to checkout to fulfillment, with no developer involvement for content. The warranty form, serial number validation, and multi-language form support all feed into the same self-service model.

An Ongoing Partnership

I started working with Sonnenglas in February 2024. The collaboration continues as an ongoing product partnership. This is not a project-based engagement where I deliver a scope and leave.

That means building Christmas shipping logic when the holiday rush approaches, setting up Easter promotion mechanics in spring, and making sure new product launches like the Lichtkaraffe 2025 have everything they need on the technical side. The platform is not a finished product. It evolves with the business, and I evolve with it.

What makes this work is trust built over time. The team knows I understand their stack, their customers, and their constraints. I know they will push the platform in directions that keep things interesting. Good partnerships are rare, and I do not take this one for granted.

Every optimized page, every recovered checkout, every new market opened helps a brand that genuinely makes a difference reach more people. That is worth building for.