Vellumwire DS: A token system where each client changes one layer
A token system where each client changes one layer
Every new client started by rebuilding what already existed.
Each project began with a component library rebuilt from a blank file, even when the logic hadn't changed. The real cost showed up at handoff: new names to interpret, new spacing to check, undocumented edge cases. What was missing was a layer between component and brand.
Architecture
Core, Palette, Brand and Semantic
Structure stays fixed. Client decisions live in Brand, and components only read Semantic.
Palette
Color ramps built ahead of any client
Every ramp follows the same 25 to 950 structure, so branding a client means mapping its colors onto ramps that already exist. Seven of the eight ramps, one per role:
Brand
The same components under three brands
A card, a button, an input and badges under three client brands. Ramp, typeface and radius change, and the component code stays the same.
Components
Component states
Buttons, form controls and feedback, each with its variants and states, rendered from the same code under three brand layers.
Semantic
Components use role names like border.error
border.error means the same thing whatever ramp a client picks. A partial view of the dark mode set:
Responsive
Breakpoints were in the tokens from the start
Size and type tokens resolve per breakpoint from the start. When Instivo needed a mobile stock view mid-project, it consumed the same tokens.
In production
In production since 2023
The architecture started on Instivo in 2023, where it absorbed a mobile view that was never in scope. It is now the base of every Vellumwire build, which Afonso implements and hosts.
- 4layers: Core, Palette, Brand, Semantic
- 8color ramps built before any client
- 1layer touched to re-theme a project