How much token and component library does B2B SaaS need ?

This question often arises after the product has real users, the technical team starts to grow, and someone realizes that the interfaces are inconsistent across screens. At that point, some people want to immediately build a comprehensive component library. Sinh Vũ often advises against this: build the right thing at the right time, not the most you can.

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, when the brand changes its primary color, you must change each instance manually. If named according to purpose like color-primary, color-surface-default, you only need to change the value in one place, and the entire system updates accordingly. This is called a semantic token, meaning a meaningful token. Sinh Vũ always establishes this layer before starting to design the first component.

Naming tokens by purpose, not by appearance. This is what allows the system to be maintained after three years.

Practice principles, Sinh Vũ Studio

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

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.

The viewpoint of Sinh Vũ

In package P5, Sinh Vũ includes four layers of support: a workshop guiding the use of the entire kit, a recorded session for newcomers to review, PDF guides for each section of the repository, and a Q&A channel post-delivery. In the full package, the support channel lasts for 60 days, while the higher tier extends to 90 days with an onboarding flow for new sales and an operational team handbook.

What Sinh Vũ always asks before proposing the scale: who will own this system after Sinh Vũ hands it over? If the answer is unclear, then regardless of the level of development, that question needs to be addressed first. A design system is not a one-time deliverable; it is a living infrastructure that requires someone to operate it.

Sinh Vũ does not commit to specific ROI figures as they largely depend on how your team operates the system after handover. What can be guaranteed is: if the right things are built at the right time and there is clear ownership, the costs of content production and onboarding new members will noticeably decrease over time.