Case StudyFrom Failing Checkouts to 27 Countries: Building Sonnenglas's Global Platform

When I first opened the codebase for sonnenglas.net in February 2024, the checkout was broken. Not theoretically broken, not "sometimes has issues" broken. Users could navigate to a product, add it to their cart, and then watch the checkout fail. For any ecommerce company, that is a serious problem. For a social enterprise whose brand is built on trust and purpose, it affects how the company is perceived by every single visitor.

The store had been live for years and had a loyal customer base across Europe. But the technical foundation was cracking. Pages loaded slowly, the CMS buckled under traffic, and the checkout flow had state management issues that made completing a purchase feel like a coin flip. That is not a situation any growing brand can afford to stay in.

24 months later, the platform serves 27 countries in 6 currencies with zero downtime. This is the story of how we got there.

About Sonnenglas

Sonnenglas is a German-South African social enterprise founded in 2013. They make solar-powered mason jar lights and Lichtkaraffen, handblown vessels crafted from recycled glass in Eswatini. The products are beautiful, but the real story is the business model behind them.

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

The factory itself runs on 90% solar power from 105 PV panels on the roof. The Sonnenglas Original was the first solar light to earn Germany's Blauer Engel certification, one of the world's oldest and most respected environmental labels. The products have picked up over 20 design awards, including Red Dot, iF Design, and Good Design.

This matters for context. When the checkout breaks on a typical ecommerce store, a company loses money. When it breaks on sonnenglas.net, it hits a brand whose entire identity is built on doing things right. A broken shopping experience undermines the trust that customers place in a social enterprise. The technical problems were not just technical problems.

The Situation When I Joined

When I took over the platform in February 2024, the most urgent issue was the checkout. Users could browse products fine, but the purchase flow broke during normal navigation. Cart state got lost, form fields reset mid-entry, and payment submissions failed silently. Every day this continued meant orders that never completed.

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 load. Mobile users on slower connections had a particularly bad experience. Pages that should have loaded in under two seconds took five or more.

The CMS integration was fragile. API usage had grown far beyond sustainable levels. During peak traffic, the CMS would start returning errors, which cascaded into broken product pages and missing content blocks right when the most visitors were on the site.

Re-rendering issues caused visual glitches across the storefront. Components would flash, layout would shift, and interactive elements like size selectors and quantity inputs would lose their state. It made the whole experience feel unreliable.

Despite strong demand from customers across the globe, the store only served 2 markets. The infrastructure was not ready for expansion. And the hard constraint through all of this: the store could not go offline. Revenue had to keep flowing while every fix shipped around it.

Strategy: Triage, Stabilize, Build

The first thing I fixed was the checkout. Within the first week, 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. Fixing the root cause meant the symptoms would stop coming back.

I split the work into two phases. Phase 1 was about stopping the bleeding: stabilize checkout, fix the worst performance issues, reduce CMS API load to sustainable levels, and eliminate the re-rendering bugs that degraded the user experience. No new features, just making what existed actually work.

Phase 2 was about building for growth: multi-currency support, new market expansion, performance optimization beyond the basics, and the infrastructure work needed to scale from 2 countries to 27.

Every change shipped incrementally. No big-bang deployments, no maintenance windows. The store stayed live and 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.

What follows is a detailed look at what was built across those 24 months.

Going Global: 27 Countries, 6 Currencies

When I joined the project, Sonnenglas served two regions. By the time the expansion was complete, the store operated in 27 countries across 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 here 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, without having 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.

Beyond basic routing, each market needed its own business logic. 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 purchase from a USD market needed to redirect correctly so the recipient could redeem in their local currency.

The SKU management layer maps Shopify variants to market availability rules. 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 kind of multi-market infrastructure 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.

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 product architecture. Inventory, pricing, and variant data come from Shopify's REST Admin 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 Shopify, while pricing and stock levels stay accurate to the second.

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 Shopify product behind them. The system automatically aggregates available denominations and variants from Shopify's gift card data and presents them under the CMS-managed parent. This means the marketing team can design the gift card experience, write the copy, and choose the imagery, while the actual financial instrument stays in Shopify where it belongs.

The partial delivery system solved a real operational pain point. Sonnenglas regularly runs preorder campaigns alongside in-stock products. Before I built this, 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.

The product review system supports search, sorting, and pagination across thousands of reviews, with automatic translation between English and German. Product carousels use physics-based Embla Carousel with touch, swipe, and pinch-to-zoom on mobile. Voucher and discount codes apply at checkout with real-time validation against Shopify's discount rules.

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. Cart updates became instant. Navigation between pages stopped feeling sluggish.

The CMS optimization story deserves its own paragraph. When I audited the Hygraph API usage, the project was running at 230% of its quota. Every page render fired redundant requests. The same product data was fetched multiple times per page. At that rate, the store risked API errors during traffic spikes and significant overage charges.

My first attempt used Vercel KV as a rate-limiting layer, caching responses and throttling outbound requests. It worked in development but broke server-side rendering in production. KV reads added enough latency to push SSR response times past acceptable thresholds, and the cold-start behavior was unpredictable. I scrapped it.

The solution that worked was a multi-layered approach applied directly at the data-fetching level. A DataLoader pattern batches concurrent requests for the same resource type into single API calls. p-throttle caps outbound requests at 15 per second, just under the API limit. Request deduplication ensures that if three components on the same page need the same product 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 API 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 PNGs and JPGs now serve responsive WebP and AVIF formats at appropriate dimensions. I eliminated hydration errors across the codebase and fixed layout shifts that were hurting 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. Automated sitemaps regenerate on content changes. A Google Merchant Center feed generator exports the full catalog with market-specific pricing for Shopping ads.

The entire codebase was migrated to TypeScript. CI/CD runs type checking and linting on every pull request. Production monitoring through Axiom provides real-time visibility into errors, API response times, and edge function performance.

Results

When I joined the project, the checkout was broken. Customers across multiple markets were hitting errors, abandoned carts were climbing, and the team had no clear path to fixing it. That was the first thing I tackled, and within weeks, checkout was fully recovered. It works reliably now across all 27 markets, all devices, every payment method. No more lost orders.

Stabilization

The API layer was next. Shopify's rate limits were being hit constantly because every page load triggered dozens of unoptimized calls. I introduced request batching, response caching, and proper rate limit handling. API usage dropped from unsustainable levels to healthy, predictable patterns.

Performance followed. Product images that had been serving at 1-7 MB per file were replaced with optimized, responsive formats. Pages that took seconds to become interactive now load fast. The hydration errors that caused UI glitches and re-rendering loops were traced to their root causes and eliminated one by one.

All of this happened with zero downtime. The store kept selling through every deployment, every migration, every refactor.

Growth

With the foundation stable, we could build. The platform expanded from 2 countries to 27, a 13.5x market expansion. Six currencies with real-time pricing. Over 25 major features shipped, from Google Shopping feeds that run automatically across all markets to a partial delivery system that reduced customer support tickets.

The marketing team gained full self-service through the CMS. They launch campaigns, update content, and manage promotions without developer involvement. New products like the Lichtkaraffe 2025 and SOMO Gen6 run through the same platform, from landing page to checkout to fulfillment.

An Ongoing Partnership

I started working with Sonnenglas in February 2024. Over 24 months later, the collaboration is still going. This is not a contractor relationship where I deliver a scope and disappear. I am embedded in the team's workflow, part of the daily rhythm of building and improving the platform.

That means supporting Christmas shipping logic when the holiday rush approaches, building Easter promotion mechanics in spring, and making sure new product launches 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.

Sonnenglas is proof that technology done right can amplify a brand's mission. Every optimized page, every recovered checkout, every new market opened means more solar lamps in more hands, and more fair-trade jobs in Johannesburg.