How many digital products are worth investing in?
The question is not 'how many users', but 'how many times are you paying for the same thing repeatedly'.
There is no hard user threshold to decide on investing in a design system. What truly matters is the number of digital surfaces that need to be kept consistent and the number of teams working on the interface, as that is where repeat costs arise. The practical principle: it is worth investing when there are two or more digital products, or one product but multiple teams interacting with the interface and starting to see the same components being recreated multiple times in various places.
- multiple digital products or teams, clear repetition is observed
- Want to standardize the base color and font first.
- industry requiring strict compliance and high quality standards
- one product, one small team, few repetitions
- Using traffic numbers as an excuse instead of considering repeat rates.
When asking "how many users are needed to justify a design system?", most business owners are asking the wrong question. The number of users indicates the scale of the product, but does not reveal anything about the costs the team is actually incurring daily. What matters is the repetition: how many times the same button, the same information tag, the same input field is being recreated, in how many places, by how many different people.
The factor that truly decides.
There are four things Sinh Vũ considers before advising on an appropriate investment level, not just traffic numbers:
- Number of digital surfaces to keep in sync: Website, iOS app, Android app, internal portal. The more surfaces there are, the higher the cost of maintaining synchronization.
- Number of teams or individuals interacting with the interface: A team of three people working on one application is completely different from three teams of fifteen people collaborating on multiple products.
- Actual repeat costs: How many times is the same component being rebuilt? If the answer is "a few times in a few places," that is a clear signal.
- Feature release rhythm: The higher the rhythm, the greater the benefit of having a standard component ready to plug in.
A large user base primarily raises demands for quality and accessibility (the ability to be used by everyone, including those with visual or motor limitations). This is the reason to do better, not a reason to do sooner or bigger.
When to choose which level
Sinh Vũ categorizes into three levels based on actual scale, allowing you to step into the exact area you need rather than creating something grand with a low actual usage rate.
Level 1: Token foundation (a base design token set for color, font, spacing). Suitable when there is one to two digital products and you want to standardize the basics first. Low cost, immediate benefits even with a small team.
Level 2: Complete system (component library, shared documentation). Suitable when there are multiple digital products and a design team working alongside a development team, noticing clear repetition between products or teams.
Level 3: Governed system (contribution process, change approval board). Suitable for large enterprises with many teams and partners using it, needing to control who can change what and through which processes.
Common errors when making decisions
- Using traffic as an excuse to build a complete system: "We have many users, so we must do it" is a leap in reasoning. The real issue may only require a basic token level.
- Wait until you are "big enough" to start: By then, the interface debt has piled up, and the cost of transitioning to a new system is much higher than standardizing early on from a lighter level.
- Create a complete system for a single product with a small team: Most components created will not be reused, and the team will waste time maintaining something that does not generate value.
When a component is recreated in dozens of places, doing it well the first time will save every team. The investment threshold should be viewed through the lens of reuse, not user count.
Nathan Curtis, EightShapes. Brad Frost, bradfrost.com.
The viewpoint of Sinh Vũ
The question "how many users" often stems from wanting to find a number to justify a pre-existing decision or to persuade superiors. Sinh Vũ understands this, but the number of users won’t protect you when the project exceeds its budget due to miscalculation.
A more practical self-check question: "Last week, did my team recreate something that others in the company had already created?" If the answer is yes, and this happens frequently, then it is time to invest, whether you have a thousand or a million users.
Decision checklist
Topic: How many digital products justify investing in a design system. Sinh Vũ guide, sinhvu.com
Select each item you find appropriate, 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.
References
Nathan Curtis, EightShapes Design Systems. Brad Frost, bradfrost.com. Sinh Vũ, A3 service document (three levels by scale).
Frequently asked questions
My company has only one application but hundreds of thousands of users, is it necessary to create a complete design system?
A large user base increases demands for quality and accessibility (accessibility, meaning the ability to be used by everyone), but it is not the main reason to create a comprehensive system. If only a small team is involved and there is little repetition between screens, you should start with a basic token level, meaning standardizing the color palette and typography, then expand when there is real demand.
I do not have a dedicated design team, only hire externally for each project, should I create a design system?
This is a case where a lightweight token foundation brings the clearest benefits: it keeps different outsourced units aligned on a synchronized product without requiring constant consultation among them. A complete system with a complex component library will be hard to maintain without an internal team responsible for operations.