Most design system money is wasted buying the right thing at the wrong time. This is what each stage actually needs.
Answer four questions before reading further.
The last answer usually identifies the stage faster than the first three. Inconsistency is a stage-one problem. Refusal to adopt is a stage-four problem, and no amount of new components will fix it.
The situation. One product, growing feature set, screens increasingly inconsistent because every new page is built from scratch.
What to buy. Foundations and a core component set. Colour, type, spacing, and the twelve to twenty components that appear everywhere. Documentation short enough that people read it.
What not to buy. Multi-platform tokens, a contribution model, a governance framework, a documentation site with search. All of it is real work and none of it has a job to do yet.
Typical scope. Six to ten weeks. Low to mid five figures at this tier.
How it goes wrong. Over-building. A studio proposes a comprehensive system because comprehensive is easier to scope and more impressive to present. Six months later a third of the components have never been used and nobody has updated any of them.
Moving on when. A second product or team starts consuming it, or the component set stops covering what you build.
The situation. A library was built once, production has moved on, and design and code no longer agree. People still use it, with local workarounds accumulating.
What to buy. An audit first. What exists, what is used, what is dead, and where the divergence is. Then targeted reconciliation rather than a rebuild.
What not to buy. A rebuild, unless the audit genuinely justifies it. Rebuilds are commonly proposed because they are cleaner to scope and price than repair work, and they throw away institutional knowledge embedded in the existing library.
Typical scope. Audit in two to four weeks, often priced separately and worth doing even if you then hire someone else for the fix.
How it goes wrong. Skipping the audit and starting over, then arriving back at the same drift in eighteen months because the cause was never diagnosed. Drift is a process problem wearing a component problem’s clothes.
Moving on when. The reconciled system holds for two release cycles without local workarounds reappearing.
The situation. Multiple teams, each with their own patterns, some overlapping, none agreeing. Consolidation is the obvious answer and everyone is quietly attached to their own version.
What to buy. Consolidation work, which is an audit across products, reconciliation of conflicting patterns, and a negotiated shared foundation. Budget significant time for the negotiation, because that is the actual work.
What not to buy. A greenfield system designed in isolation and handed to the teams. It will be technically better than what they have and they will not adopt it.
Typical scope. Three to five months. Mid five to low six figures depending on product count.
How it goes wrong. Treating this as a design problem when it is a political one. The studio produces an excellent unified system, two teams migrate, the others do not, and now you have four systems instead of three.
What actually works. Involve the teams in the reconciliation. Migrate one team properly and use the result to persuade the rest. Accept that the shared system will be a compromise that satisfies nobody perfectly, because the alternative is one that satisfies one team completely and is ignored by the others.
Moving on when. Most products are consuming the shared foundation and the requests start arriving.
The situation. The system is used. Teams want new components, exceptions, and changes, and there is no mechanism for any of it. Requests go to whoever built it, informally, and the queue is growing.
What to buy. DesignOps. A contribution model, request and review workflow, versioning and deprecation approach, release cadence, and a clear answer to who decides.
What not to buy. More components. The queue is a symptom.
Typical scope. Six to twelve weeks of process design, and it works best delivered alongside your team rather than to them.
How it goes wrong. Governance designed to be correct rather than to be used. A model requiring three approvals and a fortnightly review meeting will be bypassed within a month, and teams will go back to building locally.
The test that matters. How long from a team asking for a component to getting an answer. If it is longer than a sprint, the system becomes optional regardless of quality.
Moving on when. Contributions arrive from product teams rather than only from the system owner.
The situation. The practice works. The constraint is throughput: more requests than your team can service, and the system falls behind the products.
What to buy. Capacity. Embedded designers, a subscription arrangement, or a retained team working as part of your practice rather than a project with an end date.
What not to buy. Another project. Projects produce artefacts and leave. What you need is sustained throughput.
Typical scope. Monthly, ongoing, often with a defined number of designer or engineer days.
How it goes wrong. Buying capacity without deciding priorities, so the external team services whichever request shouts loudest and the system’s own roadmap stalls.
Most studios at this tier are distributed or European. Systems work is unusually sensitive to this, because it touches design, engineering, and product at once and depends on live conversation more than most design work.
Four hours of overlap is a working minimum. Enough for a daily standup and one working session.
Front-load the synchronous time. Foundations, naming conventions, and architecture decisions need live discussion. Component production afterwards handles asynchrony well.
Put your engineers in the room, not just your designers. The most common failure in distributed systems work is the design side agreeing something the engineering side hears about a fortnight later.
Write more than feels necessary. Decisions made in a call and not recorded get relitigated across timezones, and the second discussion happens without the person who made the first decision.
Agree the review rhythm rather than improvising it. Fixed sessions beat ad hoc requests when half the team is asleep.
If a studio publishes its own system, template, or method, spend fifteen minutes in it before the first call. It tells you more than the case studies.
Look at the naming. Component and token names reveal how the studio thinks about structure. Names that describe purpose rather than appearance are a good sign.
Look for states. Whether components carry disabled, error, loading, and focus states, or only the default.
Look at the documentation. Whether it explains when to use something and when not to, or just shows what it looks like.
Look at the accessibility handling. Whether focus and keyboard behaviour are specified at component level.
Then ask whether client systems build on it. Studios usually work from their own foundation. What they publish is a preview of your deliverable.
