Case study · Retail & eCommerce
Six brands, one engineering team, three-week launches
A retail group had six brands on six different builds, each needing its own developer. We put them on shared infrastructure without making them look or feel the same.
Project overview
Shared infrastructure where the brands must not look shared.
- Industry
- Multi-brand retail
- Client
- Confidential
- Solution
- Multi-store commerce platform
- Platform
- Shopify
- Engagement model
- Dedicated platform team
- Scope
- Component system, theming, fulfilment, reporting
- Brands
- 6 at launch
- Constraint
- Each brand keeps its own identity
- Target
- Fast new brand launches
Expected business outcomes
What shared infrastructure returned
Six independent builds meant six of every problem and six of every fix.
-
3 wks
To launch a new brand, from 5 months
A new brand is a theme configuration and a catalogue on existing infrastructure, rather than a build from scratch with its own integrations and fulfilment setup.
Measured from brief to live for the two brands launched after the platform
-
−64%
Engineering cost per brand
One component system, one fulfilment pipeline and one integration layer mean a fix is made once and reaches every brand, rather than six times with three of them forgotten.
Measured across engineering spend per brand year on year
-
+18%
Group conversion rate
Improvements proven on one brand roll out to all six immediately, so the best-performing patterns propagate instead of staying where they were discovered.
Measured across group conversion after 12 months on the platform
Business challenges
Six brands, six builds, six of every problem
The group had grown by acquisition, and every acquisition came with its own stack.
The business
A retail group operating six consumer brands across related categories, each with its own audience and identity.
The starting point
Six Shopify stores on six unrelated themes with six sets of integrations, each maintained separately.
The trigger
A conversion improvement proven on one brand took months to reach the others, and launching a new brand took five months of engineering.
What they wanted
Shared infrastructure and a shared component system, without the brands becoming visually or commercially interchangeable.
Constraints
Brand identity is the commercial asset and must not be diluted · brands have different catalogues, tone and customers · one brand's peak must not affect another's · brand teams must retain merchandising control.
Proposed solution
What we built
A platform the brand teams chose to use.
-
Component system
Shared components built for deep theming.
-
Brand theming
Layout, type, spacing and motion per brand.
-
Integration layer
One connection per external system.
-
Fulfilment pipeline
Shared, with per-brand rules.
-
Runtime isolation
Shared code, separate capacity.
-
Group reporting
Comparable metrics across brands.
Architecture
How it fits together
Simplified — the shape of the system rather than every service in it.
-
Component system
- Shared components
- Deep theming
- Per-brand adoption
One codebase, six genuinely different storefronts.
-
Integration layer
- ERP
- Warehouse
- Analytics
One connection per system, configured per brand.
-
Fulfilment
- Shared pipeline
- Per-brand rules
- Group reporting
One pipeline with brand-level configuration.
-
Isolation
- Separate storefronts
- Independent capacity
- Per-brand deploys
Shared code, unshared blast radius.
Deep theming is what keeps the brands from converging. If only colours and logos vary, the brands become the same shop in different paint within a year.
Key capabilities
What it does day to day
Six capabilities across the group platform.
| Capability | Runs | Refresh | What it does |
|---|---|---|---|
| Component system | Platform team | Continuous | Shared components with deep per-brand theming |
| Brand theming | Brand teams | Per brand | Layout, typography, spacing and motion as brand decisions |
| Integration layer | Platform team | Continuous | One connection per external system, configured per brand |
| Fulfilment | Automatic | Per order | Shared pipeline with per-brand rules |
| Merchandising | Brand teams | Daily | Each brand publishing independently |
| Group reporting | Automatic | Daily | Comparable metrics across all six brands |
Integrations
How the moving parts plug in
Built once, themed six ways, deployed independently.
Shared platform
- Component systemOne codebase
- Integration layerOne per system
- Fulfilment pipelineOne
Brand configuration
- ThemeLayout and type
- CatalogueIts own
- MerchandisingBrand team
Independent runtime
- Own storefront
- Own capacity
- Own deploy schedule
Brands adopt component updates on their own schedule. Forcing simultaneous adoption is how shared platforms become the thing brand teams resent.
Security & data
What keeps the brands independent
Shared infrastructure must not mean shared risk.
-
Runtime isolation
A peak or failure on one brand cannot affect another.
-
Data separation
Customer data separated per brand, with group reporting aggregated rather than pooled.
-
Independent deploys
Each brand deploys on its own schedule; no brand is forced to take a change.
-
Group visibility
Comparable metrics across brands without merging their customer data.
Project requirements
Share the engineering, not the identity
Multi-brand platform projects usually fail in one of two directions: the brands converge until they are interchangeable, or the sharing is so shallow that nothing is actually saved.
We drew the line at the component layer — deeply themable components, genuinely shared integrations, and no shared runtime. Brand teams kept everything that makes their brand theirs.
- One component system with deep per-brand theming
- One integration layer, configured per brand
- Runtime isolation between brands
- Independent deploy schedules
What the platform had to preserve
- 01Brand identity as the commercial asset
- 02Different catalogues, tone and customers per brand
- 03One brand's peak not affecting another
- 04Merchandising control staying with brand teams
Key challenges & considerations
Four problems with brand-by-brand builds
They feel like independence and behave like duplication.
-
Every improvement made six times, or once
A conversion improvement proven on one brand either gets rebuilt five more times or quietly never reaches the others.
What we did
A shared component system where an improvement is made once and available to every brand immediately, adopted on each brand's own schedule.
-
Six integrations to the same systems
Each brand had its own connection to the same warehouse, ERP and analytics, each breaking independently.
What we did
One integration layer serving all brands, with per-brand configuration rather than per-brand code.
-
Shared infrastructure that makes brands look alike
Most multi-brand platforms converge visually until the brands lose what made them worth acquiring.
What we did
Components built to be themed deeply — layout, typography, spacing and motion are all brand-level decisions, not just colour variables.
-
One brand's peak affecting another
Shared infrastructure that shares a failure mode turns one brand's campaign into six brands' outage.
What we did
Brands isolated at the storefront and traffic level, with shared code but no shared runtime capacity.
What we hold to on multi-brand platforms
- Share the engineering, never the identity
- Theming has to go deeper than colour
- Let brands adopt changes on their own schedule
- Shared code, separate runtime
Development process
We migrated the smallest brand first
The platform had to prove itself on a brand that could afford the lesson.
-
Component extraction
Common patterns extracted from the existing six builds, with theming depth decided by what actually differed between brands.
-
First migration
The smallest brand migrated completely, including fulfilment and integrations, and run for a quarter.
-
Theming validation
Brand teams reviewed the themed result against their brand guidelines before any further migration.
-
Rolling migration
Remaining brands migrated one at a time, each keeping its own deploy schedule from day one.
-
New brand launch
The platform proven by launching a new brand on it in three weeks.
Technology stack
Shopify with a shared platform layer
Six stores, one engineering surface.
Commerce
- Shopify
- Storefront API
- Per-brand stores
Platform
- Component system
- Theme tokens
- Design system
Integration
- ERP
- Warehouse
- Analytics
Operations
- Group reporting
- Independent deploys
- Runtime isolation
Quality assurance & deployment
Every way an order can go wrong, tested first
A defect in a store costs money directly. Payments, stock, promotions and tax were tested deliberately, including the failure paths, before the store took its first real order.
- A payment test matrix: success, decline, timeout, duplicate and refund
- Stock, pricing and promotion rules tested under concurrent use
- Speed measured on real phones over mobile connections
- Cross-browser and device checks on the full checkout
- Redirects and search rankings checked before and after launch
Deployment
- 01Rolling migrationRemaining brands migrated one at a time, each keeping its own deploy schedule from day one.
- 02New brand launchThe platform proven by launching a new brand on it in three weeks.
- 03Launch outside trading peaksThe switch was made at a quiet time, with a rollback ready and orders watched live.
- 04Monitoring and warrantyConversion, errors and speed monitored from launch, and six months of free bug fixing.
Business impact
What changed for the group
Three outcomes in the first year on the platform.
-
Brand launches in three weeks
Down from five months, which changes what acquisitions are viable.
-
Engineering cost per brand down 64%
Fixes made once instead of six times.
-
Group conversion up 18%
Because improvements now propagate.
Final deliverables
One engineering team, six brands that still look like themselves
A new brand launches in three weeks instead of five months, engineering cost per brand is down 64%, and group conversion is up 18% because improvements now reach every brand.
The brand teams kept merchandising control and their own deploy schedules, which is why they use the platform rather than route around it.
- New brand launch in 3 weeks, from 5 months
- Engineering cost per brand down 64%
- Group conversion up 18%
- Six brands still visually distinct
Handed over to the client
- 01Live storefrontTheme, apps and integrations configured
- 02Source codeTheme and custom code in the client's repository
- 03Integration documentationWhat connects to what, and how
- 04Admin trainingFor the team that runs the store
- 05Six-month warrantyFree bug fixing after delivery
Success metrics
What it runs at today
The platform as it runs today.
-
6
Brands
On shared infrastructure
-
3 wks
New brand launch
Down from 5 months
-
1
Component system
Themed per brand
-
−64%
Engineering cost
Per brand
How success is measured
How success is measured
| Measure | Outcome | How it is measured |
|---|---|---|
| To launch a new brand, from 5 months | 3 wks | Measured from brief to live for the two brands launched after the platform |
| Engineering cost per brand | −64% | Measured across engineering spend per brand year on year |
| Group conversion rate | +18% | Measured across group conversion after 12 months on the platform |
Free discovery call
Have an idea? Let's turn it into AI-powered software.
Book a free discovery call with our experts. Share your idea and we will help you shape the scope, timeline and budget, under NDA.
- Free consultation
- NDA before we talk
- Transparent estimate