How white-label architecture turned 6-8 weeks of rebrand work into 2 weeks

Component-based design system served 4 sponsors (Orange, Salt, ZKB, Alliance) with 60% lower adoption costs—while keeping UX consistent and users confident.

3-4 Min. Read

The Challenge

How might we rebrand quickly when sponsors change but users expect consistency?

When Orange rebranded to Salt (2016), the cinema app needed full redesign—new colors, logos, typography, layouts. The existing system was hard-coded. Every visual change required developer intervention. Estimated rebuild: 6–8 weeks per sponsor. With multiple sponsors interested (ZKB, Alliance), this model didn't scale.

What made this complex:

• 80% of UI changes were superficial (colors, fonts, logos) but touched dozens of files
• Sponsors wanted differentiation—but diverging UX meant fragmented experiences and higher costs
• Cinema integrations were fragile—UI changes could break ticket purchases

The Solution

Design tokens, themeable components, and architectural decoupling

What we created:

• Design token system extracting colors, fonts, spacing, shadows into swappable variables
• Themeable components (buttons, cards, navigation) adapting to sponsor branding via token swaps
• Standardized layouts so content structure stayed consistent across sponsors
• Rebrand playbook—plug in new tokens, test, ship
• Decoupled architecture—UI components consumed data, didn't fetch it (separated concerns)

The Result

4 sponsors, 1 codebase, 60% cost reduction

Flexibility isn't a luxury—it's infrastructure.

Impact:

• Salt rebrand: 2 weeks (down from 6–8)
• ZKB and Alliance onboarding: 10 days each
• 60% adoption cost drop per sponsor
• 40% faster user onboarding (users transferred knowledge across sponsor apps)
• 30% fewer support tickets (UX was predictable)
• 50% QA time reduction (rebrand cycles stopped breaking integrations)

Design Decisions

What made it work

1. White-label = brandable without rebuilding

Set clear boundaries—sponsors could customize branding (colors, logos, typography) but not UX patterns (navigation, flows, layouts). Positioned this as a feature: "Your users already know how to use this—they've used the other sponsors' apps."

Why it worked: Sponsors initially resisted—then saw the benefit. Users navigating Salt's app could easily use ZKB's. One sponsor said: "We wanted to be different, but realized familiar is more valuable."

2. Design tokens paid for themselves after sponsor #2

Extracted visual styles into design tokens. Built themeable components adapting to sponsor branding via token swaps. Created rebrand playbook.

Why it worked: Economics of reuse. This wasn't about making things "look nice"—it was about reducing cost per sponsor.

3. Loose coupling saved sanity

Decoupled architecture—UI components consumed data, didn't fetch it. Introduced data layer handling API calls separately. Components became "dumb"—received props, rendered UI, emitted events.

Why it worked: Developers could iterate UI without fear. One dev said: "I can finally change a color without holding my breath."

Final Design

Scalable platform, not custom builds

Impact: Shifted stakeholder thinking—from "custom builds" to "configurable platforms." Design systems are economic decisions, not just aesthetic ones.