Build it yourself or hire a studio to create a design system
The real question is not who will do it, but who will maintain the system after it's completed.
Outsourcing is reasonable when you need a solid foundation quickly and the internal team is still thin. Building it yourself should only be the goal when the team has enough dedicated personnel to sustain the system long-term. The most sustainable approach for most businesses today is to hire to establish the foundation, along with training, and then transfer ownership to the internal team.
- never created a system, needs a proper foundation quickly
- an internal team that is still small or busy running features
- need training and then transfer ownership to internal teams
- has a dedicated team with enough members, the infrastructure is essential for daily operations
A design system is not a project that you complete and set aside. It is a product that serves all your other products, and it requires continuous maintenance. Therefore, the question of "build it yourself or hire" is actually the wrong question. The right question is: once the system is built, who will be responsible for maintaining it?
Three key factors determining the direction
Before making a choice, you need to honestly answer these three things:
- Does the team have enough people? Self-building requires at least one dedicated person who is stable, not just working on it during spare time. If design and technical teams are busy with product features, the system will fail before it can generate benefits.
- Does the team have sufficient foundational knowledge? Building a proper system requires understanding design tokens (variables storing values for colors, spacing, typography) according to DTCG standards, versioning components (reusable interface elements), and managing changes that break backward compatibility. Without this foundation, self-built systems often go wrong from the start and need to be redone.
- How long do you need the system? Outsourcing usually results in a usable system sooner. Building it yourself requires time for the team to learn, test, fix, and then stabilize.
When to choose which direction
Hire an external studio when: the internal team is still thin or has never done a system, needs a proper foundation in a short time, or wants to avoid costly mistakes at the foundational stage.
In-house development is suitable when: there is a dedicated team with enough personnel, operating multiple digital products simultaneously, and the system is critical infrastructure that needs daily control, not allowing external interference for minor changes.
Hybrid: outsourcing construction, then transferring ownership is the most common and often the most sustainable approach. An external studio builds the foundation to the right standards, alongside training the internal team, then transfers actual ownership after a supported transition phase.
A design system is not a project. It is a product. And like any product, it needs an owner, a roadmap, and long-term resources.
Nathan Curtis, EightShapes: A Design System isn't a Project, it's a Product
Common mistakes when making a hasty decision
- In-house development with one or two people working part-time: results in a half-baked system, components lack documentation, and then are abandoned. The actual costs can be higher than outsourcing because you have to redo the work.
- Hiring and then having no one to take over: the system freezes at the studio's final version, the internal team does not understand the structure, is hesitant to make changes, and gradually stops using it.
- Confusing "renting" with "buying outright": Whether renting or building it yourself, the largest costs do not occur during setup but during maintenance. Without budgeting for maintenance, any system will fail.
- Pillar tied to an individual: when that person leaves, the entire system loses its owner. Documentation and management processes are not luxuries but minimum insurance.
The team needs enough people at a minimum level to sustain the system. If there are only people working on it casually when they have time, the system is likely to fail.
Nathan Curtis, EightShapes: Team Models for Scaling a Design System
The viewpoint of Sinh Vũ
Sinh Vũ builds the system in a way that truly returns ownership to the client team, avoiding long-term dependency. There are three phases of work: reviewing tokens, creating components with documentation, and implementing with management, all accompanied by parallel mentoring sessions with the internal technical team. The first three months of maintenance are to help the team become familiar and confident in taking over, not to create dependency.
You need to be straightforward: Sinh Vũ is a service provider, so the advice on outsourcing comes with related benefits. You should read with that awareness. Sinh Vũ's honest filter is: when the internal team is mature enough and the system is a vital infrastructure that needs daily control, building in-house is the right choice. And with a very small technical team, Sinh Vũ will clearly state that you should not attempt to build the entire system, rather than accept the work and deliver something that no one can maintain.
Decision checklist
Topic: Building your own design system or hiring a studio. Sinh Vũ Handbook, 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: Team Models for Scaling a Design System. Nathan Curtis, EightShapes: A Design System isn't a Project, it's a Product. Practical experience of Sinh Vũ Studio.
Frequently asked questions
Once you hire a studio, is the system truly yours?
Yes, if the contract clearly states the delivery of source code, design files, and documentation. The issue is not legal ownership but actual ownership: does the internal team understand and can they make adjustments themselves? Therefore, the mentoring session and the transition maintenance phase are much more important than the contract itself.
If only one or two people are doing the design, should a design system be created?
Usually not advisable to do the entire system. One person working part-time is not enough to sustain the system, and a half-hearted system is more costly than having none. Sinh Vũ often recommends that small teams prioritize unifying color tokens and typography first, stopping there, and then expanding when the team grows larger.