Should we create the design system early or wait for the product to be stable?
The answer is not about being early or late, but rather at what level and when it is appropriate to do so.
If the product is still finding its shape, creating a complete design system right now is premature abstraction, easily locking in decisions that should not be finalized yet. However, do not wait until interface debts pile up before starting, as the cost of transition will be much higher then. The right approach is to gradually standardize according to the product's maturity: create foundational tokens when colors and fonts are finalized, while saving the complete component system for when interface templates have stabilized and repeated.
- color and font are finalized even if components may change
- the product is stable, with clearly repeated interface samples
- standardizing gradually rather than doing everything at once
- the product is still in exploration, evolving every week
- the product has no real users yet
This question often arises at two extremes: one side wants to create a design system right from the start to keep everything tidy, while the other wants to wait until the product is certain before investing. Both can be correct, and both can be wrong, depending on the stage the product is in.
Why acting too early is dangerous
When the product is still in the exploration phase, meaning it is not yet clear what users need, and the experience flow changes weekly, creating a complete component library at this moment is premature abstraction. You are investing effort in establishing rules for decisions that should not yet be locked.
A common result: when a product needs to pivot, the entire library must be redone. Worse, the design team starts to feel constrained by the established system and hesitates to change even when they know it is necessary. Dan Mall calls this "premature optimization," a form of waste where the actual costs do not appear immediately but accumulate over time.
Do not start by building buttons and components. First, create the actual flow and then work backward: when you see opportunities for reuse, then distill them into a common template. Abstraction should come after identifying repetition, not before.
Brad Frost, Atomic Design
Why does waiting too long also come at a cost
On the contrary, if you let the product run without any standards, design debt will grow day by day. When the team builds the same type of button in three different ways across three screens, or when they change a color in one place without knowing how many other places need to be adjusted, that is the design debt in action.
Transition from a state of accumulated debt to an orderly system takes more effort than gradual standardization when the templates are just ripe enough. At that point, it not only requires effort to build a new system but also to clean up the old one.
How to categorize by level instead of choosing extremes
Sinh Vũ does not recommend choosing one extreme or the other. Instead, the right question is: which part of the system can be implemented immediately because it is stable, and which part should wait due to ongoing changes?
Level 1: Token foundation (tokens are atomic values like color, font, spacing that are named and shared). Can be implemented early even when the product is still changing, as brand colors and fonts are usually finalized before components. This is the least risky level and provides immediate consistency.
Level 2: Complete component system. For when the product has real users, development is steady, and you notice the same types of interface components appearing repeatedly in various places. At that point, extract them into valuable new components.
Sinh Vũ approaches how
Before proposing where to start, Sinh Vũ always reviews the existing interface to separate the stable parts from the dynamic ones. Only systematize what is stable, not the entire thing at once.
For products without real users, the straightforward advice is: focus on making the product run and finding users first. Investing in a digital design system at this stage often yields less return than investing in the product. Once the product has real signals from the market and the team begins to recreate the same thing in different ways, that is when systematization becomes valuable.
Common errors when deciding on timing
- Misunderstanding that you must work sequentially from the smallest atom is incorrect. In reality, the process is often parallel and gradually refines what has been built in practice.
- Waiting until you are "completely ready" to act all at once, while standardizing each part in phases is often more effective and less risky.
- Confusing documenting the current interface with building a design system. These are two different tasks, with different costs and values.
Decision checklist
Topic: Should you create a design system early or wait until the product stabilizes. 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
Dan Mall, Beware premature optimization, Practical Design Systems. Brad Frost, Atomic Design. Sinh Vũ, service document A3 (three levels of approach, review before systematization).
Frequently asked questions
Should a newly launched startup create a design system right away?
If the product does not yet have real users and its shape changes every week, it is not advisable to create a complete component system yet. Focus on getting the product running first. What can be done immediately is to finalize the color, font, and basic spacing into foundational tokens, as these elements change less and help the team maintain consistency even when components are still fluctuating.
Which signs indicate that it is time to create a design system?
The three clearest signs: interface templates repeating across multiple screens and groups starting to recreate the same thing in various ways; products have real users and a more consistent growth rhythm; when fixing one area, other areas shift and require time for manual checks. When these three signs appear simultaneously, the costs of a non-systematic approach begin to exceed the costs of building.