Design system as a service: how a retained design system team works, and when it beats a hire

Design system as a service is an ongoing arrangement in which an outside team designs, codes, documents, releases and supports your design system month after month, while a named person inside your company owns it and decides what it becomes. It beats hiring when the system is young or stalled, when the work comes in bursts, when you need design and code from the same people, or when you cannot build a team fast enough. A permanent in-house team is the better choice for a large, settled system that many products ship on every day.

Whether it works comes down to one thing: someone inside owns the system. A retained team with no internal owner turns into a component factory, shipping parts that nobody has agreed to use.

What "design system as a service" means

The phrase has two meanings, and both matter here. The first is the commercial one: you retain an outside team to run the system for you. The second comes from inside product companies. At Web Directions Summit in 2019, Alexandra Skougarevskaya described how Atlassian's design system team stopped treating its system as a product for products and started treating it as a service for the designers and engineers who use it.

The two meet in one test. Whoever runs the system, it is judged by whether product teams find it faster and safer than building their own. A retained team that ships components but leaves product teams working around them has failed that test, however polished the library looks.

It is also different from a design subscription, which sells a queue of design tasks such as screens or marketing assets. A design system service runs one shared product: its foundations, components, guidance and releases.

Who does what between the retained team and you

The right-hand column is the part buyers underestimate. At minimum it needs a system owner with the authority to say no, product and frontend leads who come to the reviews, and product teams with time set aside to adopt each release. Without that, the retained team is designing for an organisation that is not listening.

What a retained design system team does in a month

A working month has a recognisable rhythm, whatever the size of the system:

1. Intake. Requests arrive from product teams with the need, the teams affected and the pattern they tried first.
2. Triage. Each request ends in one of six outcomes: reuse an existing component, extend one, create a new shared one, keep it local to one product, reject it with a reason, or retire something that no longer earns its place.
3. Build. Components are designed and coded together, with every state, accessibility behaviour and theme, and both versions describe the same thing.
4. Document. Guidance is written in plain words, so a designer, an engineer or an AI coding tool picks the right component for the job.
5. Release. Design and code ship as one version, with notes on what changed and what a migration involves.
6. Support adoption. The team pairs with product teams on migrations, answers questions and removes whatever blocks a team from switching.
7. Review with the owner. What shipped, what was refused and why, where teams forked, and what comes next.

A monthly fee raises a fair question: what did it buy? A count of components answers it badly. The evidence worth reading is adoption by product and component version, local forks and their reasons, the time from a request to a decision and a release, and the migration blockers still open. These are the measures we set out on our design system governance and adoption page, because they show whether the system is doing its job rather than whether the team was busy.

When a retained team beats a hire, and when it does not

Nathan Curtis set out three team models in his 2015 essay, Team Models for Scaling a Design System: a solitary team that shares its own library, a centralised team that serves other product teams, and a federated group of designers from several products deciding together. Two of his observations place a retained team inside those models rather than outside them. A centralised team, he notes, may be implementing "a vision produced by an outside agency". And a federated model still needs a central group of staff dedicated enough to write decisions down and keep the system alive. An outside team can be that central group, as long as the decisions stay inside.

The resourcing data explains why companies look outside at all. In zeroheight's 2025 Design Systems Report, 79 per cent of respondents said they had a dedicated design system team, yet 41 per cent of companies under 500 employees and 54 per cent of larger ones felt they did not have enough people, with demand outpacing what system teams could supply. Having a team on paper and having enough of one are different things.

A retained team fits when:

• The system is young or has stalled. You need it designed, coded and adopted before you can justify permanent roles. If you are unsure whether the moment has come, our design system maturity model helps place your team.
• The work comes in bursts. A frontend migration, a second product joining the system or a change to shared foundations needs more people for a period, then fewer.
• You need design and code from one team. A system is only real when the coded component matches the designed one. Hiring for that means filling several roles at once: a designer with systems depth, a frontend engineer who cares about component interfaces, and someone who writes the guidance.
• Your engineers outnumber your designers. A large engineering team can build components and still lack the design judgement a system's visual language, states and rules depend on.
• You cannot hire in time. The roadmap will not wait for a recruiting cycle, and the people you need may not be available when you need them.

Hire, or choose something else, when:

• The system is large and settled. Many products ship on it every day and the work is steady. A permanent team holds the context and authority better than any outside team; zeroheight's average system team at companies of 500 or more employees was nine people.
• Nobody inside will own it. No outside team can supply that, and no contract can make up for it.
• You want parts produced cheaply from a finished specification. When the judgement is already done, a production-focused build team is the better buy.
• You need one expert view, with your team doing the building. That is a consultant's job; our guide covers when to hire a design system consultant.
• You want screens or marketing assets on a queue. That is a design subscription.

Ownership decides whether it works

Curtis's list of what centralised teams lack applies twice over to an outside one: context from real products, the power to get product designers taking part, and day-to-day visibility of each product's problems. A retained team can close those gaps only through a person inside who has them.

The zeroheight data points the same way. Among the best-adopted systems, a dedicated team was barely more common than elsewhere (81 per cent, two points more than other teams), while a hybrid model, in which a central team and product teams share the work, was 27 points more common. Having a team mattered less than how decisions ran, and decisions need someone inside with the authority to make them.

So the owner's job is specific. They decide what the system covers, rank the backlog, rule on contested exceptions and make room in product roadmaps for adoption. For how those decisions are shared out across an organisation, see our guide to design system governance models. The retained team's job is to make the supported route faster than a fork. When building locally is quicker than asking the system, teams fork, and no amount of component output fixes that.

How Tcules runs a retained design system engagement

We take on strategy, implementation and governance and adoption as one piece of work, in design and in code, aimed at a system that lands in the products your customers use rather than in a library few people open. The engagement is a way to keep the system moving while your owner decides, not a cheaper substitute for a hire.

Your system owner works directly with the senior designer who leads the work. Our design engineers build the coded components to fit your frontend, in your repositories and your release routine, so a component is reviewed as working behaviour, not only as a drawing. Researchers and other specialists join when the work calls for them. In Benchmark Gensuite's enterprise suite, we began at the shared layer and used coded prototypes so its teams could judge interaction behaviour and feasibility in working code, while Benchmark kept responsibility for implementation across the wider platform. That split, with us shaping the system and the client owning it, is the one this model depends on.

Ongoing work is priced as a fixed monthly fee for the team and capacity we agree together. You can change the team or end the work with two weeks' notice, and there is no minimum term. A good first step is smaller: one component family, one product area's rules or an audit of what you already have, at a fixed price agreed before we start.

If you are comparing providers, we also publish a shortlist of design system agencies and consultants.

Questions to ask any design system provider

• Who inside our company will own the system, and what will you need from that person each month?
• Do the same team design and code the components, and do both ship as one version?
• How does a request from a product team become a decision, and how long does that take?
• What will we see each month to judge the work?
• How will you work inside our codebase, tools and release process?
• Who covers the work when the lead is away?
• What do our product teams need to give for each release to be adopted?
• When the engagement ends, what do you hand over, and who on our side will have run a release before you leave?
• How is the work priced, and what notice ends or changes it?

A provider who answers the first question vaguely is selling components, not a system.

How to end it without the system dying

Plan the exit at the start, because the point of the engagement is a system your teams can run. Before the retained team steps back, check that:

• Your owner has run a release cycle from intake to release notes while the outside team watched rather than led.
• The contribution and exception route is written down and in use, with real requests from your product teams going through it.
• Releases run in your pipeline, under your accounts, with no step that depends on the outside team's access.
• Every component's documentation covers its options, states and when to use it, so new screens can be built without asking.
• A decision log explains why things are the way they are, including what was rejected.
• The adoption measures are handed over with a baseline, so you can tell whether use rises or falls after the handover.
• The open migrations are listed, with an owner for each.
• The team tapers rather than stops, so your people take over one responsibility at a time.

Documentation is what lets a system outlive the people who made it. For Auxentios' industrial quoting product, planned to run to more than 200 screens, we produced documented components, variants, design tokens and layout rules so its developers could generate new screens from them. A retained engagement should end the same way: with a system your own people can extend.