Writing · 8 min read · Feb 2026
A small design system that scales
Big design systems fail quietly: nobody uses them. Lessons from building Kestro, a system that started with twelve components and now powers four products.
Every team I've worked with has had the same dream: one perfect library that covers every case. And almost every one of those libraries ended up as a beautiful Figma file that engineers ignored and designers detached from within a month.
When we started Kestro, we did the opposite. We shipped twelve components in six weeks and let real product work tell us what to build next. Here's what made that small start scale.
Tokens before components
Components change constantly; foundations rarely do. We spent the first two weeks only on colour, type, spacing and radius tokens, with light and dark values from day one. Once those were stable, every component inherited consistency for free — and theming a new product took an afternoon instead of a quarter.
Build what's used three times
Our rule was simple: a pattern joins the system only after it appears in three places. Until then it lives in product code. This kept the library small, honest and full of things people actually needed — not things we imagined they might.
“A design system isn't a library. It's an agreement between people.”
Docs are part of the product
Each component got a one-screen guide: when to use it, when not to, and a live example. No essays. We also ran a weekly thirty-minute office hour — the single biggest driver of adoption, because it turned questions into improvements within days.
Measure adoption, not size
We stopped celebrating component count and started tracking how many new screens used the system. When that number passed 90%, we knew Kestro had become the default way of working, not an extra step.
Start small, build on solid foundations and listen harder than you design. A system people love at twelve components will grow naturally; one they ignore at three hundred never will.
© 2026 Alex Rivera