When to hire an agency for a design system (and when to wait)
Four thresholds decide it: repeated surfaces, release cadence, who owns it after handover, a fixed date. Below them a design system costs more than it returns.
In this piece
Hiring an agency to build a design system is a timing decision. Which studio you pick matters second. What decides the outcome is whether the product already repeats itself enough for a system to pay back: the same table across four screens, the same form logic in two codebases, the same button rebuilt by whoever picked up the ticket.
This is written for the person signing the invoice. Four thresholds say now. A shorter list says wait six months. Below is how to tell them apart, and what to scope first when the answer is yes.
What a design system returns, and how fast
Two studies put numbers on the saving. Figma's data science team ran a controlled exercise and found that designers with access to a design system completed the same objective 34% faster than designers building from scratch. Sparkbox tested the developer side with IBM's Carbon system: across eight developers, one simple form page took a median of 2 hours with the system against 4.2 hours from scratch, 47% faster.
Both samples are small and both measure a single task. Read them as an order of magnitude: a system takes roughly a third off the cost of building interface the system already covers. The last clause carries the whole argument.
The arithmetic follows from repetition. Take a team shipping eight new screens a quarter at about five combined design and front-end days each. That is 40 days of interface work per quarter, so a 35% saving returns 14 days. Assume a foundation plus a first component set at 30 to 60 days of build. Payback lands somewhere around the third or fourth quarter, and the system keeps paying afterwards. Run the same numbers on a team shipping two screens a quarter and payback arrives long after the product has changed shape.
Why waiting until it hurts costs more
The default rule in product teams is to wait until inconsistency becomes painful. By then the bill has two lines. You pay to build the system, and you pay to migrate every surface that drifted while you waited. Migration is the expensive half: it touches shipped code, it competes with the roadmap, and it needs QA on screens nobody planned to reopen. How that drift accumulates is the subject of component drift.
Moving early has its own failure mode, and it is not construction. Design systems die at adoption, and the most reliable way to kill adoption is to deliver a large library of components nobody asked for. Netguru's account of adoption pitfalls names the pattern: teams try to cover every scenario at launch, and the components that were never grounded in a real screen go unused. A 60-component library handed to a product with 11 screens is an expensive style guide.
When the answer is genuinely unclear, a five-day audit produces the numbers the decision needs at a fraction of a build. The checklist we use is public: how to run a design system audit in 5 days.
Four thresholds that say now
1. The same component exists in three places
Count real duplicates, not planned ones. Search the codebase for the button, the input, the modal, the table. Three or more independent implementations of the same element, or two surfaces that have already diverged (marketing site and app, admin console and customer product), is the strongest single signal. Repetition is what a system compounds against. Without it there is nothing to amortize.
2. More than three people touch the interface every week
One designer working with one front-end developer holds consistency in their heads, and they do it faster than any documentation. That stops working at roughly three to five people, or the week the first contractor joins. Cadence weighs as much as headcount: a weekly release train produces more divergence in one quarter than a monthly train produces in a year.
3. Somebody owns it on the Monday after handover
This is the threshold buyers skip and regret. Reading Zeroheight's annual surveys, NN/g reports that most design-system teams are 2 to 5 people, that organizations above 5,000 employees still average only 9 to 11, and that these teams rarely pass 20 to 25. The floor matters more than the ceiling here. The minimum viable owner is one designer and one developer with named hours, not a wiki page and good intentions. If nobody has those hours, delay. An unowned system decays faster than the code it was meant to fix.
4. There is a date you cannot move
A rebrand, a platform migration, a second product line, an enterprise procurement round, or an accessibility deadline. The European Accessibility Act has applied since 28 June 2025 under Directive (EU) 2019/882, and the questions now arriving through procurement (accessibility statements, evidence of conformance) are answered once at component level or repeatedly at screen level. A fixed date turns a system from an efficiency argument into a delivery dependency, and that overrides the arithmetic above.
Three of four is a yes. Two is a conversation about scope. One is a no.
When to wait six months
Wait while the product is still deciding what it is. The concrete signals:
- The core flow changed twice last quarter and the next change is already scheduled.
- One surface, one designer, one front-end developer.
- Fewer than 15 distinct screens and no second product on the roadmap.
- No named owner after handover.
- Runway under 12 months with product-market fit still open.
Waiting does not mean doing nothing. The cheap version keeps the door open: define tokens (color, type, spacing, radius, elevation) and stop there, then keep a written inventory of components as they appear. One to two weeks of work, almost free to throw away, and it turns the eventual system into a refactor instead of an archaeology project. The order to build in later is in design system structure.
What to scope first when the answer is yes
The first engagement should end with a foundation, not a catalogue.
- Tokens and theming, including dark mode if the product will ever need it. Retrofitting theme support into hardcoded values is the most predictable rework in this category.
- Eight to twelve components, chosen by counting what the existing screens use rather than by copying a library index. In most products that set covers the majority of the interface.
- An accessibility baseline inside the components: focus states, contrast, keyboard paths, labelling. Fixed once, inherited everywhere.
- A version and contribution policy: who may add a component, what counts as a breaking change, how a release is announced. Governance decides whether the system is alive in a year.
- Documentation attached to the code, not a separate site nobody updates.
The delivery model that holds is hybrid. The agency builds the foundation at a pace an internal team cannot match while also shipping product, and the internal team owns the growth from there. Where each side wins is covered in in-house vs agency for a design system, and the commercial shapes (project, retainer, shared ownership) in design system pricing.
The same product, two opposite answers
Take a B2B product with a customer app, an admin console, and a marketing site. Three buttons in three codebases. Two designers, four front-end developers, weekly releases. A second product line is signed for the next quarter, and enterprise deals have started asking for an accessibility statement.
That is four thresholds out of four. The arithmetic: roughly 45 days of build for a foundation plus ten components, against 14 days a quarter recovered on new interface work, plus accessibility work that would otherwise repeat on every screen. Payback around the third quarter, and the second product line launches on the system instead of forking from the first one.
Now change two variables. Remove the second product line and the admin console, leave one designer and one front-end developer. The same team should spend two weeks on tokens and an inventory, then revisit in six months. Same buyer, same category of product, opposite answer, because the thresholds moved.
Sources
Frequently asked questions
How much does hiring an agency for a design system cost in 2026?+
Scope drives the number, so ask for it broken down rather than as one figure. The four axes that move it: how many components, how many consuming codebases, whether theming and accessibility conformance are in scope, and whether governance and documentation ship with the build. A foundation plus eight to twelve components sits in a different order of magnitude from a full library across three products. Ask what happens to the price if the component count moves by five, because that answer tells you whether the estimate was built or guessed.
Can we start with tokens now and add components later?+
Yes, and it is the cheapest correct move when the thresholds are not met. Tokens encode brand and rhythm (color, type, spacing, radius, elevation), so they survive most product pivots. Components encode product decisions, which is exactly what changes while a product is still finding its shape. Define the tokens, use them in whatever you build next, and keep a written list of components as they appear. When you do commission the system, the work is a refactor rather than a rewrite.
What happens to the system after the agency leaves?+
It decays unless somebody owns it, so settle ownership before signing rather than at handover. Name the person, the hours per week, and the release process. Ask the agency for the version policy, the contribution rules, and a handover that includes the build pipeline and the publishing steps, not only the code. Without an owner a system drifts back into per-screen decisions within two or three release cycles, and that drift is where the migration bill comes from.
Do libraries like MUI or shadcn/ui remove the need for an agency?+
They remove part of the build, not the decision. An off-the-shelf library gives you tested primitives with a lot of accessibility work already done, which is real value. It does not give you your tokens, your density, your empty states, your error language, or the governance that stops twelve developers from forking a component each. On top of a library the engagement gets smaller: tokens, theming, the eight to twelve product-specific components, and the rules. Say that out loud during scoping and see whether the proposal changes.
Related services
Studio
Start a project.
We write about what we build. Tell us what you want to build.