Design system consulting is outside help to audit, build, or maintain a shared component and token system across design and code. It comes in three shapes you can actually buy: a fixed scope audit, a time boxed build sprint, and an ongoing maintenance retainer. Each has its own duration and its own price band. Ranges observed across providers run from a few thousand dollars a month for a retainer up to six figures for a full multi platform build. One question sorts the vendors on the first call: will the consultant ship components into your repository, or only into your Figma file.
If you are still deciding whether you have a system at all or just a set of components, sort that out first with design system vs component library.
The Three Shapes Design System Consulting Comes In
Almost every vendor page blurs audit, build, and maintenance into one four phase diagram with one price attached. That is three different purchases wearing one label. They carry different risk, different duration, and different failure modes.
| Engagement shape | Typical duration | What you should get | Observed market range | |---|---|---|---| | Fixed scope audit | 2 to 3 weeks | Inventory of design and code, a ranked drift list, an adoption estimate, a migration sequence | Usually billed inside the hourly bands below, 50 to 400 USD per hour | | Time boxed build sprint | 6 to 12 weeks | Token source and pipeline, a foundational component set in code, docs, one product surface migrated | Sits inside full project engagements, 50,000 to 500,000 USD by scope | | Ongoing maintenance retainer | Monthly, rolling | Review capacity, releases, migration support, drift monitoring | 3,000 to 15,000 USD per month |
The audit is the shortest, cheapest, lowest risk purchase. It is the right first buy when nobody in the room agrees on what is broken. A design lead says the Figma library is a mess. An engineer says the library is fine and the codebase is the problem. An audit settles that with evidence. What it delivers is a diagnosis, not a system. For what the audit itself should cover on both sides, see what a design system audit should check.
The build sprint produces tokens, a component set, and a pipeline, sequenced against real screens rather than a wish list. Its failure mode is a beautiful build with no adoption path. Guard against it with one contract line: at least one product screen must ship on the new components before the sprint ends.
The retainer is the shape almost nobody sells honestly, because it turns a project into a subscription. It is worth real money when it buys review capacity, regular releases, and migration support while your team catches up. It is not a substitute for an owner inside your company. Design system governance covers the process a retainer actually runs month to month.
Buy them in sequence, never as one bundled quote. And never sign a build before an audit has told you what already exists.
What Design System Consulting Costs, and What Moves the Number
Every figure below is a range observed across providers. It is not a quote and it is not our rate. Treat the numbers as a way to sanity check a proposal, not as a price list.
| Pricing model | Observed range | When it fits | |---|---|---| | Independent or freelance design system designer | 50 to 150 USD per hour | Audits and focused component work | | Agency or consultancy hourly | 100 to 400 USD per hour | When you need several roles at once | | European design system studios | 100 to 180 EUR per hour | Regional teams, similar scope to the above | | Monthly maintenance retainer | 3,000 to 15,000 USD per month | Ongoing review, releases, migration support | | Full project engagements | 50,000 to 500,000 USD | End to end builds, scope dependent |
Once you pick a route, the payment structure is its own decision. Fixed price vs hourly design work covers which one protects you in each case.
Where a complexity ladder does get published at all, it runs roughly 50k at the low end, 100k to 150k for mid complexity, 200k to 250k for high, and around 500k for extreme. It is a rare piece of honesty in a market that mostly says "contact us."
It still is not enough to plan against. A four notch slider tells you the shape of a market. It does not tell you which notch your product lands on, or why.
Here is what actually moves a quote:
- Platform count. Web only is one number. Web plus iOS plus Android is a different project.
- Consuming products and teams. Every extra team adds review, migration, and negotiation.
- Migration scope. Do existing screens move onto the system, or only new ones?
- Token pipeline. Building one from scratch costs more than extending one that works.
- Code in scope. Or does the deliverable stop at Figma?
- Documentation. A named deliverable, or an afterthought nobody budgeted?
- Post launch maintenance. Does the consultant stay, or hand off and leave?
Two quotes for the same brief can differ by an order of magnitude and both be defensible. "Design system" covers a Figma kit and a multi platform token pipeline equally well. The vendors are not lying. They are answering different questions.
That ambiguity is exactly why the next question matters more than the price.
The Question That Vets Any Vendor: Will You Be in My Repo
Look at the deliverables on almost any design system consulting page. Library. Kit. Style guide. Pattern documentation. Every one of those words describes a Figma file. Almost none of them commit to shipping components into the repository.
So ask it plainly on the first call: will you be in my repository, or only in my Figma file?
Both answers can be legitimate. What is not legitimate is an answer that stays vague until the invoice arrives.
Figma only means your engineers still have to build everything the consultant drew. That work is real, it is weeks of it, and the estimate you were shown did not include it. You are buying a specification, and you are paying for implementation twice.
Repository access means something different. It means a pull request with a name on it, a review from your team, and a component that renders for a real user. The consultant works inside the constraints your engineers live in.
Three follow ups turn a vague answer into a concrete one:
- Which pull requests will carry your name?
- Who reviews them on your side before they reach us?
- What does CI have to pass before a component counts as done?
When You Should Hire In House Instead of Buying Consulting
Every vendor with an incentive to sell you this leaves the next part out. Here it is anyway.
Design system work splits into two things: a bounded push and a continuous function. Consulting is good at the push. It is a bad fit for the function. If the work arrives weekly and never stops, the money is better spent on a headcount.
| Signal | Better route | |---|---| | Nobody can say what components exist today | Buy an audit | | Tokens and components need building once, and no team can spare a quarter | Buy a build sprint | | Review requests arrive every week from several product teams | Hire in house | | One product, one team, no second platform planned | You likely need a component library, not a system | | A rebrand or platform migration with a hard date | Buy a sprint with a fixed end | | Adoption slides back after every cleanup | Hire, because the problem is ownership, not craft |
Now the uncomfortable version. A retainer that quietly replaces a hire is the most expensive way to run a design system. You pay agency rates for work a salaried owner would do better, because that owner sits in your planning meetings and can say no to a component request.
A consultant with an incentive to stay will rarely be the one to raise this. If the wider hire versus contract question is still open, fractional designer vs full time walks through the same tradeoff across design roles.
What Each Timeline Actually Produces
Vendors quote 8 to 16 weeks against 6 to 12 months in house, and break down neither. Here is both, at a level you can check a proposal against.
A two week audit realistically produces a diagnosis and nothing else: what exists on both sides, how far apart they are, and the order to close the gap in. Two weeks is enough to look and to sequence. It is not enough to also build, and anyone promising both in that window is doing one of them badly.
A six week build sprint realistically produces a token source and pipeline, a first set of foundational components in code, documentation for those components, and at least one product surface migrated onto them as proof. Think buttons, inputs, cards, and layout primitives, not every screen in the app. It does not produce a finished system.
A retainer month realistically produces review turnaround on proposals, a release or two, migration support for a team that is moving screens over, and drift monitoring. It is capacity, not a milestone. Some months it looks quiet, and that is what a healthy month looks like.
The honest caveat: none of these end with the system finished. A design system stops being a project on the day the last screen migrates, and that date almost always falls after the consultant has gone. A proposal implying otherwise is selling a completion that does not exist.
Which raises the question buyers ask last and should ask first.
Handoff and Exit Criteria: What You Own When It Ends
This is the number one fear buyers carry into these conversations, and almost no vendor page answers it. Write the ownership checklist into the contract before you sign.
- The repository and the published package are yours.
- The Figma library sits on your organization account, not the vendor's.
- The token source lives in your repository.
- Documentation is hosted on infrastructure you control.
- No part of the pipeline depends on a vendor seat or license.
Exit criteria are the part buyers forget to define. Name them at kickoff, not in the final week when you have nothing left to trade:
- A stated adoption target on named surfaces, not "improved consistency."
- A documented contribution path anyone on your team can follow.
- A named internal owner who has merged at least one change themselves.
- A written backlog of what was deliberately left undone, and why.
The single strongest handoff mechanic is cheap and almost never contracted: before the engagement ends, your internal owner ships one component through the entire process, with the consultant reviewing rather than building. Proposal, review, tokens, code, docs, release. If that has never happened, your handoff is a document, not a transfer.
That internal owner inherits an ongoing process, and the review, release, and deprecation routine is what it looks like once the consultant is gone.
Red Flags When Buying Design System Consulting
Nobody publishes a list of how to spot a bad design system vendor, because every page ranking for this term is one.
A quote arrives before anyone has looked at the codebase or the component inventory. That is a price for an imagined scope. It will be revised, and the revision only ever goes one direction.
Deliverables are described only as artifacts, never as adoption. A library nobody imports is a cost with no return. If no proposed deliverable is a number, ask why.
No migration sequence for screens that already exist. New screens are the easy half. The hard half is the couple of hundred screens already shipped, and a plan that skips them is a plan for a second design system.
Team size is fixed regardless of scope. Four people on every engagement prices their bench, not your problem.
No named exit criteria and no handoff plan. The engagement has no defined end. That is a business model, not an oversight.
Vague answers about who maintains it afterwards. "We can discuss a retainer later" is an answer. Just know it is the answer you are getting.
No pilot. They want to build the whole system before a single product team uses any of it. You will not know the components are wrong until they are all built.
Case studies with before and after screenshots only. No adoption number, no migration timeline. Pretty screenshots survive engagements that failed.
The Evaluation Script: What to Ask on the First Call
Run this on any vendor. Run it on us. If we cannot answer these cleanly, we do not deserve the work either.
- Will you work in our repository, or only in Figma?
- Who on your side reviews the pull requests?
- What does your audit deliver that a screenshot review would not?
- Which of our existing screens gets migrated inside the engagement?
- What is the adoption target, and how will you measure it?
- Who owns the token source when you leave?
- What is your handoff plan, and who on our team executes it?
- What would make you tell us not to hire you?
- What does month two of a retainer look like when nothing is broken?
The last two are the tells. A vendor with no answer to what would make them decline the work has never declined any. A vendor who cannot describe a quiet retainer month honestly is selling capacity rather than outcomes.
Buy the Diagnosis Before the System
Three lines, in order. Audit first. Build only what the audit justified. Retain only if the work is genuinely bounded, and hire the moment it stops being.
My own position is simple: I work inside the repository, not beside it. A component I have not shipped through your pipeline is a suggestion, and suggestions are the cheapest thing in this market.
If you want a diagnosis before you commit to a system, that is where our design system consulting work starts. An audit is the sane first purchase, and it is a small one.