Design systems at 10 vs 100 people are completely different jobs

Design systems at 10 people and 100 people are completely different jobs.

At 10 people, a design system is mostly a shared color palette, two button styles, and a Figma file someone built in a weekend.

It works because there are two designers in the same room who can resolve inconsistencies in a single conversation.

At 100 people, that same file is a liability. Three teams interpret it differently. Components get forked. The mobile app drifts from the web. New designers inherit a system nobody can fully explain.

The company that needed a library at 10 now needs architecture at 100.

The problem is most teams do not realize this until they are already at 100. By then, technical and design debt are compounding together, and the redesign costs 10x more than it would have at 50.

What changes between the two stages:

At 10: you need consistency. Shared variables, a basic component set, documented colors and type.

At 100: you need governance. Token architecture, a component ownership model, a clear deprecation process, documented decisions, and a handoff protocol engineering actually uses.

I built a 2,287-component system for Rakbank across 15 product teams. I built the Red Dot Award-winning system for Sector Alarm across 7 platforms.

Both were cases where the company was already at 100 but running the system they had built at 10.

The fix in both cases was not a full redesign. It was a 2-week sprint to establish the architecture, clean up the token layer, and rebuild the core component set with enough documentation that any new designer could onboard themselves.

If your team is growing and your design system is starting to feel like a problem, that is usually the signal you are already past the inflection point.