The small-team trap
Every year or two a small product team decides it needs a design system. Six months later the system exists, shipping velocity has collapsed, half the components do not match the live product, and the designer who championed it has quit. This happens in startups, in-house brand teams, and small agencies with roughly equal frequency.
Design systems are a real, compounding asset at scale. Below that, they are mostly overhead. The interesting question is not whether your team should have one. It is where on the spectrum of formality your team should sit this year, and how to move up the ladder without jumping a rung.
When a design system pays off
The payoff curve is driven by two variables. How many distinct components you reuse, and how many people need to use them consistently.
The N components rule
A design system starts paying for itself around 30-40 reusable components across 3-5 product surfaces. Below that, a disciplined Figma file and a tidy CSS token layer will get you most of the benefit at 10% of the cost. Above that, the cost of inconsistency (visual drift, redundant engineering, onboarding friction) exceeds the cost of maintaining the system.
The M developers rule
With one or two developers and one designer, verbal consensus in a Slack channel is a viable governance model. With four or more engineers, particularly across multiple squads, you need something written down. The coordination cost of every component decision being re-litigated for every new feature compounds fast.
The real triggers
Past those rough thresholds, the concrete situations where a small team needs to invest:
- Multi-brand. One agency servicing several brands, or one parent brand with sub-brands needing visual differentiation. Think how Atlassian runs Jira, Confluence and Trello off a shared spine.
- Multi-product. Marketing site, logged-in app, embedded widget, email templates, each with its own stack but a shared visual identity.
- Multi-channel. Web, mobile, kiosk, physical signage. Tokens become the lingua franca across platforms that cannot share components.
- Distributed team. Designers and engineers in different time zones, where asynchronous clarity matters more than ad-hoc chat.
If none of those apply, you probably do not need a design system yet. You need a style guide.
The lightweight ladder
For small teams we recommend an incremental approach. Each rung solves a real problem and creates the conditions for the next.
Rung 1: design tokens
Start with tokens. Named variables for colour, typography, spacing, radius, shadow, motion. No components yet. Just a shared vocabulary that designers and engineers both use.
The trick is to define them in one place and generate platform-specific output. Tokens Studio for Figma is the current sensible default on the design side. On the engineering side, tokens can be exported to CSS custom properties, Tailwind config, or native platform files via Style Dictionary or the Tokens Studio pipeline.
Even without a single reusable component, tokens alone kill the most common sources of drift: hex codes copy-pasted with a typo, line-heights that differ by 2px across templates, three slightly different shades of "primary blue" that nobody can reconcile.
Rung 2: a Figma library
Once tokens are stable, build a Figma library of the components the team actually reuses. Not the full Material catalogue. The 15-25 components your product genuinely shares: buttons, inputs, form fields, cards, navigation, table rows, empty states.
A Figma library with variants and auto-layout, wired to token variables, closes most of the design consistency gap for small teams. It does not yet promise engineering consistency, but that is the next rung, not this one.
Rung 3: Storybook (without a component library yet)
Before you invest in a full component library package, instrument Storybook against your existing application components. Storybook gives you a rendered inventory of what is actually shipping, which is often surprisingly different from what the Figma library says is shipping.
This surfaces drift honestly. Now you can see that the "primary button" has six variants in production, three of which are accidents. That visibility alone is worth the week it takes to set up.
Rung 4: a shared component library
Now, and only now, is it worth extracting components into a shared package. The trigger is a second surface joining the product (a new app, a marketing site redesign that wants to share chrome with the app), not an abstract desire for "cleanliness".
At this rung the tooling stack tightens up: Storybook as the living documentation, Chromatic or Percy for visual regression on PRs, a versioned npm package (private registry or monorepo) consumed by every surface. Changelogs matter. Semver matters. Deprecation matters.
Rung 5: governance
The last rung is governance. An RFC process for new components, a rotating owner or a small working group, a contribution guide. This is where most small teams genuinely do not need to go. The overhead is only justified once enough people need to contribute that "ask in Slack" stops working.
The tools worth knowing
A short, opinionated list of what we reach for on client work.
- Figma with variables, variants and auto-layout. Still the default for design libraries.
- Tokens Studio for Figma to author and export tokens across platforms.
- Style Dictionary to transform tokens into CSS, Tailwind, iOS and Android outputs.
- Storybook for rendered component documentation and engineering-side source of truth.
- Chromatic for visual regression tests and review workflows tied to Storybook.
- Radix UI or React Aria as accessible primitives to build on, rather than rebuilding button and dropdown semantics yourself.
Tailwind configured with token-derived values sits nicely under all of this and removes most of the motivation for a bespoke CSS-in-JS layer.
When to stop
A design system is not a product. It exists to make the real product easier to ship. If your system work is slowing down feature delivery for more than a sprint at a time, something is wrong. Usually it is that you have jumped ahead of where you should be on the ladder. Drop back a rung. Tokens and a Figma library alone will carry most small teams further than anyone expects.
If you are weighing up whether to invest in a design system, or want a second opinion on one already in flight, come and talk to us.
