The fragmentation tax.
When I joined Ripple in 2020 there was no shared design system. An audit across the two core products found twelve button styles, uncoordinated layouts, and divergent brand interpretations. The cost was not how it looked; it was how slowly anything moved: a feature routinely took a full quarter to travel from design to code, because every team first had to reconcile mismatched UI foundations before building anything new.
Design fragmentation wasn't a rounding error; it silently taxed velocity across every team.
The tax was invisible because it was distributed: a few rebuilt components here, some design drift there, spread across every team and never line-itemed. To make it undeniable, I ran a weekly audit: each issue took one component, showed it side by side across the products, and estimated the engineering hours lost re-implementing it. Stacked week over week, the inconsistency stopped reading as housekeeping and started reading as an operational bottleneck with a number attached.
Fragmentation is not a chapter a company closes; it is a pressure that returns at every new scale. Two products diverge into twelve button styles. An acquisition arrives with an interface no shared token has ever touched. A business line, moving fast enough, grows an entire design system of its own. What follows is the same fight fought three times, each at a larger scale. That is why what wins it has to be architecture, not policing.
Isolate the variance; share everything else.
The fix had to attack coupling, not appearance. I distilled Ripple's brand into a platform-agnostic token layer for color, typography, iconography, and motion, so that brand lived in named values, not in component code. Every product shares that single brand root; what legitimately differs between surfaces is theme: a dark mode, a density, a product context. A theme is a change of token values at the semantic layer, with nothing downstream refactored. That is the architecture's first principle in miniature: isolate each axis of real variance into one layer, and share everything else by construction. It is the decision that later made the system portable enough to absorb an outside stack and, eventually, to merge sibling systems.
Components without governance regress to fragmentation, so the second bet was operational: federated governance instead of a central bottleneck, a repeatable intake → scope → build → review → release pipeline that lets any team contribute under a shared quality bar. The framing that won executive sponsorship was that the system is a product, measured by adoption and reuse, not a visual-polish project. The counter-pressure is real: distributed contribution drifts if the review bar slips, and the smallest components, icons especially, demand the most governance, not the least.
Contribution without a shared review bar isn't federation; it's fragmentation returning.
The architecture had a consequence I designed for deliberately. A token-decoupled, contract-driven system can take on a product it did not originally build: tokens, components, and responsive page layouts together supply a working shell, so bringing an outside stack onto the standard becomes a matter of composing from the system and wiring in data rather than designing from nothing. That turned the design system from a consistency tool into infrastructure for growth-by-acquisition, the proof of which sits behind the build.
Re-architecting the system as an AI substrate.
A mature system invites a harder question: what is it for, once an agent can author code? My answer reframes the medium. Design tools are visual abstractions of software: they cannot faithfully hold conditional logic, real data shapes, async and error states, or entitlement-driven variants, so the designs engineering builds from quietly encode assumptions that later have to be unwound in code. Code is the source of truth, and with AI assistance designers and product managers can now work directly in the codebase at acceptable friction.
When code is the medium, what you design is what you ship.
On that footing the system takes on two capabilities. The first is generative UI: a user describes intent in natural language, and an agent consults the system and composes real components into a runnable scaffold wired to mock data. The second runs in the other direction: every generation, every edit a user makes to the output, every validation failure is a signal about where the system is thin. That feedback loop is the part that compounds: the output becomes an input, and the system evolves from observed demand instead of anecdote.
Two things make it infrastructure rather than novelty. A service layer built on the Model Context Protocol (MCP), the emerging standard for exposing tools and context to agents, makes the system legible to any agent in the development environment. Generation also stays context-aware, reusing the same Entity → Entitlement → Role model that runs through the rest of my work. The tools, the contracts, and the markers are behind the build.
Adoption was never the finish line.
Go behind the build to see what the system had to absorb, what it had to become, and where it goes next.