Two heritage European glassware brands · VISEO Asia engagement
One Theme Architecture, Two Brands, Every European Market
Two heritage glassware brands, sold across multiple European markets, needed consistent performance and conversion discipline without either identity getting flattened into a shared template.
Context
Two heritage European glassware brands, sold internationally, built during my time at VISEO Asia. One in tableware, one in bakeware, with related but distinct brand identities, each operating across multiple European markets.
The problem
Two brands, several markets, and a shared need for consistent performance and conversion discipline, without either brand’s identity getting flattened into a shared template that reads as generic. Multi-market retail also carries a quieter risk: performance regressions that only show up in one currency configuration or one region’s checkout, invisible until a customer in that specific market hits them.
The constraint
Each market needed its own currency and, in places, its own pricing and promotional logic. But maintaining a separate theme fork per brand per market was the fast way to guarantee drift. A fix applied to one fork silently not present in the other four, discovered only when a customer or a QA pass caught the inconsistency.
The approach
I built on a shared, minimal Shopify 2.0 base with brand-specific theming layered on top through settings and sections, not forked code, and used Shopify Markets to handle currency and market-level configuration as data rather than duplicated templates.
The alternative I rejected was a theme fork per brand: faster to ship the first market, and slower and riskier for every market that came after it, since every fix has to be found and reapplied by hand across every fork.
The result
One theme architecture serves both brands across every market they operate in, with Core Web Vitals optimized and validated, and a clean, CRO-oriented purchase flow held consistent regardless of market or currency.
What I’d do differently
I’d formalize which settings are brand-specific versus shared as documented convention earlier in the build. It was clear in my own head from the start, but writing it down sooner would have made ongoing maintenance easier to hand off to someone who wasn’t in the room for the original decisions.