Design systems as product: treating components like a startup

A design system without adoption is just a component library nobody uses. At Preply, I own the design system and frontend developer experience as an internal platform product. That framing — “internal platform product” — changes everything about how you prioritise, measure, and communicate.

I track adoption the same way I’d track feature adoption in a consumer product: which components are being used, which are being worked around, where engineers are writing custom CSS instead of using the system. The data tells you where the system is failing its users.

Developer experience is user experience. Build times, local dev environments, CI pipelines — these are the “onboarding flow” for your internal product. If it takes 45 seconds to see a change locally, engineers will find workarounds. If the component API is confusing, they’ll build their own.

The most interesting recent work has been integrating the design system with LLM code assistants via an MCP server. When an engineer asks their AI assistant to build a component, it now knows about our design tokens, component APIs, and patterns. That’s reduced component integration time significantly.