How a design system the startup kept rejecting became a continuous investment that paid for itself.
When I joined Futuur, the product was fragmenting faster than we could ship it. The same button existed in several versions.
More delivery produced more debt, not less.
Without reusable foundations, every new feature was a fresh chance to diverge.
The design system was necessary but not sufficient. The real problem was how design and engineering worked together — the DS initiative is where that shows up most clearly, so that's the story I'm telling here.
The build wasn't the hard part. Our one front-end engineer had wanted a component library for a while but never had a way in.
So I partnered with him, turned his blocked want into a case for the CEO, and reframed the ask. Instead of a project, I proposed an investment rate: reserve roughly 25% of one developer's sprint capacity to grow the system continuously, while feature work kept moving.
04. My execution strategy
Review Components on Figma prioritized by their usage frequency.
Defined guidelines, naming and tokens.
Created the guidelines and usage examples.
Reserve 25% of sprint time to iterate storybook.
Reinforce the DS usage.
I won't claim the design system alone caused that — a team gets faster for many reasons over a year, and I didn't instrument it well enough to isolate its exact contribution. What I can say: these gains are consistent with removing the specific frictions I set out to remove, and the trend held as the practices became the team's default rather than my initiative.
I should have started with the tokens — the layer everything else depends on.
What looked like a design-system problem was really a team-maturity one.
Small, continuous investments bought more consistency and more speed than any freeze-and-rebuild ever would have. And doing that work in the open, without authority, is how I earned the influence I have now.