Most design system writing comes from teams of sixty. The patterns make sense at that scale — a documentation site, a versioned npm package, a dedicated maintainer, a governance model. Then a team of three reads the article and tries to apply it. The result is six months of design-system work that doesn't ship product.
We've built design systems for small in-house teams six or seven times now. The pattern that keeps working is almost embarrassingly small: one Figma file, a token list under forty entries, maybe a dozen components, and one engineer who knows where everything lives. The discipline is in what you don't add.
What a three-person team actually needs
The job of a design system at small scale is to make every new screen start from a known-good base. Not to enable a thousand variants. Not to scale to a future team of forty. Not to ship as a public component library. Just: when you sit down to design the next thing, you don't have to redecide the type scale, the colour palette, the radius, or the button height.
- 01A type scale of six sizes, not twelve. Display, h2, h3, body, small, mono — beyond this, most teams pick variants by feel and the scale drifts within a quarter.
- 02A colour palette of nine values: surface (3 tones), text (3 tones), accent (1), state (success, error). Anything more is sketches not yet decided.
- 03Spacing on a single base unit — 4px or 8px. Use multiples; don't introduce a half-step until you've explained the need three times.
- 04Roughly twelve components: button, input, textarea, checkbox, badge, card, list-item, container, divider, dropdown, modal, toast. If you want a thirteenth, ask first whether it's a variant of one of these.
What goes wrong when you build too much
A team of three building a forty-component library hits the same wall every time: the design system becomes its own product. Someone has to maintain it. Versioning matters. Changes break consumers. A docs site appears. A bot reviews PRs. Eventually the work of maintaining the system exceeds the work of shipping the product the system was meant to enable.
Tokens before components
If you only do one thing, do this: write down the tokens. Colour values, spacing scale, type sizes, radii, durations, shadows. Forty entries or fewer. Stash them in a single file your engineers can import. Stash them in a Figma variable collection your designers can reference. The rest of the system can grow opportunistically; the tokens are the contract that lets it grow without drift.
When a new screen needs a colour that isn't in the tokens, you have a real decision: add it (and accept the increase in surface area), or use what's there. Both answers are fine. The system creates the conversation that otherwise wouldn't happen.
Components only when you've drawn it three times
The honest rule we use: don't componentise a pattern until you've drawn it three times manually. Once is a one-off. Twice is a coincidence. Three times is a pattern worth lifting into the library.
Lifting earlier means you abstract a design decision that wasn't ready to be made, and then you spend the next month wrestling the prop API instead of building screens. Lifting later means you reproduce the pattern by hand a few extra times — measurable cost, fixable.
Premature componentisation is the leading cause of design-system bankruptcy at small studios.
What we hand off as the design system
When we close an engagement, the design system isn't a documentation site. It's: one Figma file with named variables and components, a tokens.ts file in the codebase that re-exports those values for Tailwind, a components/ folder with the dozen primitives, and a one-page Markdown README that says where everything lives and what changed in the last release. That's enough infrastructure for a team of three to extend the work without us. Anything more is borrowed weight.
Looking at a design system that's grown beyond your team's ability to maintain it? We've trimmed enough of them now to have opinions; the discovery call is the right place to talk about which parts to keep.