For retail groups running multiple brands, the old assumption was that more brands mean more complexity: three brands, three codebases, every feature built three times over. It doesn't have to work that way. The retailers building the strongest multi-brand operations are collapsing separate systems into one, using a flexible design system to give each brand its distinct identity within that shared foundation.
What "shared codebase" actually means
A shared codebase means one repository of theme code, with brand-specific values held in a separate configuration layer. For example, if you change a brand's primary colour, it will flow through to that brand only, but if you build a new product card pattern, every brand has the opportunity to use it. The mechanic that makes this work is a clear separation between what's universal and what's brand-specific. So the shared layer (cart, PDP, checkout) is where engineering investment compounds and the brand-specific layer (colour, typography, copy, imagery) is where each brand keeps its identity. This is then where the in-house team has the most freedom to iterate.
"The goal of any multi-brand work is to dissolve the boundaries between design and development. To create the shortest, most efficient path between someone's imagination and what customers can see."
The Figma-to-code bridge
The part of this model most retailers undervalue is what happens between design and engineering. In a standard handover, a designer's file and a developer's code drift apart over time until no one's sure which is correct. A genuinely unified design system closes that gap: variables for colour, typography, spacing and imagery are defined once in Figma and applied across components. When a brand's primary colour changes, every instance updates automatically, in the design file and in the code that ships to production. New components built in code flow back into the design library too, so the designer's working file always reflects what's actually live.
As one of our engineers put it, describing the old process versus the new: "The designer creates a picture of a website, gives it to the developer, who has to measure everything and write code. Back and forth we go. This eliminates that. The design is alive."
Why this matters for retail groups
The business case isn't engineering elegance, it's velocity, consistency and in-house team speed. Under a shared codebase, a new brand launches inside the existing framework in weeks, brand-level content changes become fully autonomous for the in-house team, and one new integration is built once and available to all.
A second-brand build that would take five months on a separate codebase can be measured in weeks once the framework exists. Group-level investments, like a new PDP component or a third-party integration, become available to every brand for close to zero extra cost. And once the framework's in place, marketing and content teams can launch campaigns and adjust brand-level work without engineering involvement, freeing engineers for the work that actually needs their expertise.
Multi-region: the same logic at a different scale
The same architectural logic extends to multi-region selling. For retailers selling internationally, the question is no longer whether to operate one store or many, but how to balance regional autonomy with operational efficiency. Shopify Markets handles currency, language and tax within a single store for retailers running uniform pricing, catalogue and fulfilment across markets. Expansion Stores give regional teams their own catalogue, app stack and storefront content where fulfillment models, app stacks or trading activity genuinely differ by region, without rebuilding the foundation each time.
How this looks in practice
KOOKAÏ runs six storefronts across Australia, New Zealand, the US and Europe from a single Melbourne HQ, using Expansion Stores so each region controls its own catalogue, fulfilment setup and app stack. The practical effect: a Find in Store integration essential to Australian retail sits only on the Australian storefront, and a campaign tool trialled in one market stays there until it's proven elsewhere. The complexity of operating across four continents is contained within the storefronts where it actually lives.
CSD Brands built its shared framework around Neverland, its most operationally complex label, then extended it to KSCY and NXP. Building to Neverland's standard meant the foundation could handle whatever the other two brands needed. Each brand keeps its own storefront and visual identity while inheriting group-level investments in PDP improvements, checkout extensions and integration patterns built once. The outcome was a 4.8x site speed improvement across the group, with new features built for one brand available to the others by design rather than by porting.
What retail groups underestimate
The most common failure mode is treating a multi-brand build as one project repeated three or four times, rather than a foundation built once and applied multiple times. The first brand on the codebase carries disproportionate cost, because it's funding the foundation every subsequent brand benefits from. Every brand after it is faster and cheaper. The retailers who pull this off invest in the design system as an ongoing discipline rather than a one-off deliverable, with a team that has real authority to make decisions affecting every brand.
This is one chapter from Shopify at Scale: Designing Transformation for Enterprise Retail, our guide with Shopify on headless versus headed, configuration versus custom code, unifying retail and digital and what makes a transformation keep paying back after launch, drawn from our work with JB Hi-Fi, KOOKAÏ, The Good Guys, Beaumont Tiles, 99 Bikes and SHEIKE.
Shopify at Scale: Designing Transformation for Enterprise Retail
A practical guide for senior technology leaders evaluating, planning or running a Shopify transformation.