How much design token and component library does a B2B SaaS need?
The answer depends on the number of surfaces that need to be synchronized, the size of the team, and the product stage, not on expectations for perfection.
You need tokens and a complete component library when there are three or more surfaces that need synchronization, the engineering team is growing, or you are serving multiple brands and interfaces. Before reaching that threshold, building a core token layer named according to purpose is sufficient and wiser. Most importantly, there must be someone to own the system after it is built; otherwise, all investments will gradually fade away.
- From three surfaces or more need to be synchronized, the technical team is growing.
- Many brands or themes need to be served.
- High feature delivery speed requires a consistent framework.
- Single product, small team, yet to find market fit.
- Creating a massive component library too early only to discard it when pivoting.
This question often arises after the product has real users, the engineering team begins to grow, and someone notices that the interface is inconsistent across screens. At that point, some people want to immediately create a large component library. The more appropriate advice is often the opposite: build the right thing at the right time, not the most possible.
Token first, component second.
A design token (design identifier: values such as colors, font sizes, spacing that are named and stored in a structured way) is the foundation. Without a foundation, a component library is just a collection of images recoded.
The key point lies in naming. If you name the token based on the form like blue-500, then when the brand changes its primary color, you have to change it manually in every place. If named according to purpose like color-primary, color-surface-default, then you only need to change the value in one place, and the entire system updates accordingly. This is called a semantic token, meaning a semantic token. This layer should be built before designing the first component.
Naming tokens by purpose, not by appearance. This is what allows the system to be maintained after three years.
Practical experience.
When is a complete component library needed?
It's not always necessary. Here are three practical thresholds to consider:
- From three surfaces (surface: touchpoint interfaces like web app, marketing page, mobile, email) or more need to be kept synchronized at the same time.
- The technical team is large, meaning there are many designers and engineers working independently on the same product.
- There are many brands or multiple interface themes that need to be served, such as white-label products or various service packages with different appearances.
Below these thresholds, the costs of building and maintaining a library often do not recoup before the product pivots. During the phase of searching for product-market fit, building a massive library is a misaligned investment.
When to choose which direction
Only build core token layers: Single products, a small team of fewer than five people, not necessarily aligned with market fit, interface still in testing. Low cost, sufficient to maintain basic consistency and easy to adjust when pivoting.
Create a complete token and component library: Many surfaces need synchronization, a large team, multiple themes or brands, and a high feature release speed. This is the threshold where investment starts to make sense.
Inherit from open-source libraries and customize: You need to move quickly, and the budget in the early stages is limited. Libraries like Radix, shadcn, and Chakra provide component behavior, while your brand token layer sits on top to create a unique appearance. This is a practical direction and nothing to be afraid of.
Common errors when building systems
- Creating a massive component library too early only to discard it when the product changes direction.
- Naming tokens by color instead of purpose, making rebranding later a complete redo.
- Confusing a Figma UI kit with a design system. A UI kit is visual. A design system includes usage rules along with tokens and documentation. Without the latter two, the technical team will interpret freely, and the results will gradually diverge.
- After building, not assigning anyone to own the system. This is the most common mistake and causes the most damage. A system without an owner will drift away from the source reality within six to twelve months.
Who owns the system after it's built
Regardless of the direction you choose, the design system is not a one-time deliverable; it is a living infrastructure that needs someone to operate it. You should appoint someone early to manage the tokens and library, with the authority to stop deviations from standards and the time to dedicate to that task regularly.
If you have not answered the question of who owns the system, you should resolve that before discussing whether to build large or small. The benefits of the system largely depend on how the team operates it afterward, so there is no reliable common ROI metric for all teams. Subject: How much design token and component library does a B2B SaaS need. Sinh Vũ's guide, sinhvu.com Tick each item that applies or that you can already answer, then print or save as PDF to take with you. If you have marked most of the signs above, this is the time to discuss in more detail. Sinh Vũ can help you review and propose a direction.Decision checklist
References
Building the Foundation: Design Systems, Tokens & Why Every SaaS Product Needs One, Rootcode. SaaS Design System Guide: Scale UI Without Chaos, F1Studioz. 9 B2B SaaS Product Design Trends in 2026, Taqwah. Practical experience from Sinh Vũ through the brand operating system package.
Frequently asked questions
We already have a Figma UI kit, is that enough?
Not enough. The Figma UI kit is the visual layer, while the design token is the rule layer, specifying which colors to use for which purposes and where to apply spacing. Without the token layer, the technical team will translate freely from Figma to code, and the results will drift over time. The two must go hand in hand; they cannot replace each other.
Does inheriting open-source libraries like Radix or shadcn compromise brand identity?
Not necessarily. These libraries provide the behavior and structure of components, while your brand token layer sits on top to determine colors, fonts, and spacing. The result looks unique to you but is not built from scratch. This is a reasonable approach for the early stages when budget and time are limited.
When do you know it's time to upgrade from core tokens to a full component library?
When you start seeing the same component being built repeatedly in different places, or when you onboard new designers or engineers without any documentation to help them start correctly. That is a clearer signal than any scale milestone.
This article is for reference. The scope, pricing, and specific commitments of Sinh Vũ are detailed in the proposal and signed contract.