How extensive does a multi-product B2B SaaS need its digital design system ?

For multi-product B2B SaaS, the question is not "Should we build a digital design system?" but rather "To what extent and when should we build it?" The economic rationale is clear: a component takes significant effort to build correctly, but when reused in dozens of places within a multi-product organization, that cost is distributed. The reasonable investment level does not depend on ambition but on the number of teams interacting with the interface.

Three investment levels based on the problem

Sinh Vũ categorizes investment levels into three tiers, corresponding to the phase and actual scale:

• Level 1: Token foundation. For one to two products, a team of fewer than five people, still seeking product-market fit. Standardize colors, typography, and spacing into token variables according to DTCG (Design Tokens Community Group) standards. Add ten to twenty of the most commonly used components. Enough to unify the interface without being constrained when the product frequently changes direction.
• Level 2: Complete system. For design and engineering teams working on multiple products in parallel, when the same component is being recoded in many places. A library of forty to eighty core components, Storybook documentation, one-to-one integration with Figma. This is the most worthwhile investment for mature B2B SaaS.
• Level 3: Governed system. For organizations with multiple internal teams and partners using it. Adds an RFC (Request for Comment) process, adoption metrics, and a federated team model so each product both uses and contributes back to the system.

Factors that determine the level

Before making a choice, you need to honestly answer these questions:

• Currently, how many products and how many teams are interacting with the interface?
• For the same component, such as a data table or filter form, how many places is it coded separately?
• Is the product already used by real users and expanding, or still in testing?
• Once the system is established, who will be responsible for maintaining it and handling change requests?
• How many technology frameworks is the team currently using in parallel, such as React or Vue?

For B2B SaaS, the interface is often dense: tables, forms, charts, and nested filters. Inconsistency between modules is not just an aesthetic issue; it directly impacts the learning speed of business users, who must perform repetitive tasks daily.

Common errors

• Creating a complete system when there is only one product and the team has fewer than three people. The result is often a neglected system after a few months because no one has time to maintain it.
• Designing tokens and components in Figma but not linking them to actual production code. The technical team still codes from scratch because they don't trust the documentation.
• Not appointing a responsible person. The system remains stagnant while the product progresses, and after a few quarters, the team starts to overlook the system and create separate branches.
• Chasing the number of components instead of covering real interface scenarios. A system with two hundred components but lacking error states for forms or skeleton loading for tables is still insufficient.

The approach based on components pays dividends even with the smallest products. The key is to think about reusability from the start, rather than focusing on corporate-level polish.

Brad Frost, Design Systems Q&A

Sinh Vũ's viewpoint

For B2B SaaS projects, Sinh Vũ starts by reviewing the existing interface, identifying repetitive components, and standardizing them into tokens according to the DTCG standard. This step often reveals that the team is maintaining three to five variants of the same button color without anyone knowing which one is correct.

Only then build the core components, prioritizing those that appear most frequently in real products rather than following the component list of a famous design system. For B2B SaaS, complex data tables, multi-step forms, and empty states are often much more important than carousels or avatars.

One thing Sinh Vũ states clearly: if the technical team has fewer than three people or the product does not have real users, focus on the MVP first, then the design system later. Investing in the system when the product has not found product-market fit is betting on the wrong order.

The team management model should gradually shift from centralized to federal as the number of products increases, allowing each product to both use and contribute back.

Nathan Curtis, Team Models for Scaling a Design System (EightShapes)