The buyer's guide
Systems rarely fail during the build. They fail in the eighteen months afterwards, and most of what determines that is decided before you sign.
01
Not a committee, not a rotating responsibility, not “the design team.” One person with authority to approve components, reject off-system work, and allocated time to do it.
If you cannot name that person, you are not ready to buy a system. Buy an audit instead, or an embedded engagement where the studio stays, or scope something small enough that maintaining it is not a job. A system with no owner degrades into a stale library people route around, and you will have paid for the privilege.
This single decision explains most of the price variation you are about to see in proposals.
A design library means your engineers build and maintain the code side. That is real work, needs planning, and needs someone to keep it in step with the design files. A coded system costs more and removes that dependency.
Deciding this after you have collected proposals produces the worst outcome, because you end up comparing quotes for two different jobs.
Systems sit across both functions, and engagements go badly when the two sides have different expectations arriving in.
Agree in advance: what framework the components will target, whether an existing internal library is being replaced or wrapped, who reviews contributions, and where the system will live. If design wants Figma-first and engineering has already standardised on something, resolve it internally rather than paying a studio to mediate.
Almost nobody starts from nothing. There is usually a partial library, some inconsistent patterns, and at least one abandoned attempt.
Inventory it before briefing. What exists, what is used, what is quietly dead. This shortens discovery and stops you paying a studio to find out what your own team already knows.
02
Every studio you add costs you time and costs them unpaid effort. Narrow lists produce serious proposals.
Engineering-first studios, product studios with a systems service line, enterprise and DesignOps specialists, and full-practice studios price and behave differently.
Shortlist within one type. If you compare an engineering-first quote including a versioned package against a design-library quote, the gap will look like a discount and is actually a different scope.
The most useful filter available. Ask each candidate for a system they built more than two years ago and what state it is in now.
Studios that have stayed involved will tell you specifics. Studios that only launch will change the subject to a newer project. Both are legitimate businesses, and only one has watched what happens after the excitement fades.
Everyone experienced has one. A candid answer about a system that stalled, and what they now do differently, tells you more than six polished case studies.
03
Request a contribution guide, release notes, a migration guide for a breaking change, and the governance model from a real engagement.
Studios that have run systems in production have all of these and will be pleased to be asked. Studios that have built libraries will offer more component screenshots.
Ask how they get product teams to actually use the system. Listen for whether the answer is about tooling or about people.
The technically correct answer involves easy contribution paths, fast turnaround on requests, and the system solving problems teams already have. Answers that rely on a mandate from leadership indicate a studio that has not had to win adoption on its own merits.
The difference between a delivered system and a capable team is enormous, and only the second one survives.
Ask what enablement is included: pairing, documentation for maintainers, training sessions, a period of supported contribution. Studios that treat handover as an afterthought leave you dependent on them or stranded.
Named people, their role, what share of their time you get, and whether the engagement includes engineering as well as design. Ask what happens if that person leaves mid-build.
Speculative components reward studios willing to guess before understanding your constraints. Ask for relevant systems, a proposed process, a named team, and a point of view on your specific situation. If you need to see thinking applied to your product, pay for an audit phase.
04
Where does the studio's responsibility stop. Audit only, foundations and components, full system with governance, or system plus a maintenance period. Proposals are frequently vague here and the vagueness always costs the client.
Commonly scoped separately and commonly assumed included: accessibility implementation in components, documentation site build, token pipeline and tooling setup, migration of existing products onto the system, training and enablement, and any maintenance after delivery.
That last one is the most expensive assumption in this category.
Proposals often quote a number of components. Establish what counts as one, whether variants and states are included, and what happens when you need more.
A button with six variants, five states, and three sizes is not one component in effort terms, and the ambiguity here is a reliable source of mid-project friction.
Systems timelines assume your engineers are available for consultation, your stakeholders review promptly, and nobody changes the brand halfway through. Add contingency for your own side.
05
06
07
