The pitch is real
A well-built design system genuinely delivers on its promises: faster development, consistent UI, fewer QA bugs, easier onboarding for new engineers. We've seen teams double their feature velocity after implementing one.
But the pitch has a caveat: timing matters enormously.
When to build one
You have more than 3 engineers touching the frontend
Below this threshold, consistency happens through communication. Above it, you need a system. The cost of "just ask Rahul how the button should look" scales linearly with team size — and Rahul will eventually leave.
Your product has reached feature stability
If you're still pivoting — changing core user flows, rethinking navigation, redesigning key screens — a design system will slow you down. You'll spend as much time updating the system as you save by using it.
Wait until your core product patterns are stable. Then systematise them.
You're building multiple products or platforms
If you're expanding from web to mobile, or building an admin panel alongside your customer-facing app, a shared design system prevents the products from diverging. Without one, you'll end up with two slightly different versions of every component.
When not to build one
You're pre-product-market-fit
At this stage, speed of iteration matters more than consistency. Build ugly prototypes, test them, throw them away. A design system is an investment in scale — and you don't know if you'll scale yet.
You have one developer and one designer
You don't need a system. You need a Figma file with your components and a conversation about conventions. Don't over-engineer your process.
You want to "do it right from the start"
This sounds responsible but usually results in a design system that doesn't match what the product actually needs. Build the product first. Extract the system from what you've built. The patterns will be better because they're based on real usage, not assumptions.
What a good design system includes
At minimum:
- Design tokens — colours, spacing, typography, shadows defined once
- Component library in Figma — with auto-layout, variants, and named layers
- Component library in code — matching Figma 1:1, with props that mirror variants
- Documentation — when to use each component, when not to, and examples
At maturity:
- Contribution guidelines — how to propose new components
- Versioning — so consumers can upgrade on their own schedule
- Visual regression testing — automated screenshots that catch unintended changes
How we build them
Our approach is extract-then-systematise:
- Build the first 3–5 screens of your product
- Identify the repeating patterns — buttons, cards, form fields, layouts
- Extract those into a component library with clear APIs
- Document the usage guidelines
- Replace the ad-hoc implementations with system components
This takes 2–3 weeks for a typical product. The alternative — designing a system upfront before building anything — takes longer and produces worse results.
The bottom line
A design system is infrastructure. Like all infrastructure, it should be built when the cost of not having it exceeds the cost of building it. For most products, that moment comes around the 4–6 engineer mark, after the core product has stabilised.
Build it too early and you'll maintain a system nobody uses. Build it at the right time and you'll wonder how you ever shipped without one.