One component, two brands
Juniper, a plant-care subscription, acquired a second brand and needed both checkouts running on one codebase before the next billing cycle.
- Client
- Juniper, DTC commerce
- Scope
- Checkout flow, 9 components
- Timeline
- 48h first draft, 5 days signed
The problem
Two brands, one engineering team. The acquired brand, Northwind, shipped a checkout that looked nothing like Juniper's: different accent, different radius, different density. Forking the component tree would have doubled every future fix.
The brief was blunt: one checkout, themed per brand, and nothing hand-painted. If a value could not be traced to a token, it should not exist.
Three moves
Read the system as built
Wraith inventoried both checkouts from the repo, not the Figma. 61 styles resolved to 38 real decisions; the other 23 were drift, flagged and queued for deletion.
Token the differences, not the components
The two brands diverge in exactly 38 tokens: accent, ink, radius scale, and spacing density. Every component reads those tokens; no component knows which brand it is rendering.
Re-theme and prove parity
Both themes rendered side by side, every state, every breakpoint. The signed deliverable included the parity matrix, so engineering merged with zero visual QA surprises.
Before and after
What shipped
- 2
- brands on one component tree
- 38
- tokens carry every difference
- 0
- components forked
- 48h
- brief to first reviewed draft
Nnamdi E.
Senior Designer, Wraith
Rejected the first AI direction: the radius mapping flattened Northwind's character. Second pass kept both brands honest.
Illustrative case, composed for planning purposes. Names and numbers are placeholders.
Your product could be case 02.
First draft in 48 hours, a named designer signs everything, pause anytime.