A design system your whole product speaks
You are buying the shared parts your screens are built from and the written rules for changing them. The second half decides whether the first is still true in three years.
Talk to a software engineer
Write in through the form. We reply within one business day.
The three questions in the room are the same question
01
The side signing for it
Proof that this differs from the one already paid for. An in-house build nobody adopted, or a redesign applied to twelve screens that then stopped, and asking again is hard while that attempt is still half visible.
02
The side that owns the repository
A written answer to what happens the first time something in here has to change. Whoever owns the code owns it after the last invoice, and every shortcut taken in month two becomes a call at 11pm in year two.
03
The design lead and the frontend lead who have to build on it
A named owner, because they hold a veto through simply not adopting it. A maintainer in the 2022 Sparkbox Design Systems Survey, which drew 219 responses, put it this way: We are growing and just built our design system two years ago. But since there is not a dedicated person/team to manage and maintain, I see lots of inconsistencies. Sparkbox sells design-system work, publishes its sample and its recruiting method, and publishes no return-on-investment figure.
We write the change rules before the first component, and one document answers all three: what counts as a breaking change, meaning an update that stops your existing screens working until someone fixes them, who signs off before a component is removed, and how a team asks for what is missing.
USWDS major versions across the 1,003 federal sites that declare one
The risk lands after the build, once the people who made it have moved on. Of the 1,003 federal sites declaring a well-formed version of the US Web Design System, 567 sit on a superseded major, more than four years after the current one shipped on 28 April 2022.
Show data table
| Segment | Value (sites) | Share |
|---|---|---|
| v3 | 436 | 43.5% |
| v2 | 538 | 53.6% |
| v1 | 28 | 2.8% |
| v0 | 1 | 0.1% |
Every superseded major has an end of life, the date after which nobody fixes the version you are on. Upgrading is a recurring cost with dates you can read years ahead.
Source: the GSA Site Scanning census.
What counts as a breaking change, and who decides?
Semantic versioning is the three-number label on a release saying how risky an update is. Third number, bug fixes only. Second, new things added safely. First, something you rely on has changed and you have work to do. A breaking change stops your screens working until someone fixes them.
| Published sentence | Where | Fetched |
|---|---|---|
| Whenever you see a minor or patch update for a package from the Carbon Design System you should feel confident that you can update without anything breaking in your project. | IBM Carbon versioning guide | 29 Aug 2026 |
| Typescript definitions for component APIs are provided on an as-is basis and are not bound to semver. This includes type additions, changes, or removals. Breaking changes may happen across patch or minor versions. | The same IBM Carbon file | 29 Aug 2026 |
| Whenever you see a minor or patch update to a package from the Primer team you should feel confident that you can update without anything breaking in your project. | GitHub Primer versioning doc | 29 Aug 2026 |
| Eight consumer-breaking changes tallied on maintainers’ own issue trackers, two in a patch release and six in a minor, each with an issue URL. Three more were title level only, release type unconfirmed, so they are excluded. | Category evidence E2 | 29 Aug 2026 |
| So sorry that this happened in a patch release, definitely understand how annoying/frustrating it can be for breakage to occur in a non-major release from a package. | A Carbon maintainer, issue 5287 | 29 Aug 2026 |
Open them yourself: IBM Carbon's versioning guide, GitHub Primer's versioning doc, Carbon issue 5287.
A deprecated component still works, is on notice, and will be removed, and you are meant to get a window and a replacement to move to. The US Web Design System states a minimum 45-day public comment period before a new component is added. In those same documents we found no published requirement, and no stated period, for removing one. Across seven major published design systems, one states a quantified period in writing between announcing a removal and making it: Shopify Polaris, at least one month with removal at the next major.
USWDS contribution guidance and lifecycle-phases.yml, read 29 August 2026
Category evidence E2, seven published design systems measured 29 August 2026
How many days of notice does a component get before it is removed, and where is that written down?
Sources: the USWDS contribution guidance, its lifecycle-phases.yml.
Our rule, governing every figure we print: we use a figure when its method and its sample are disclosed, whoever published it. We followed each back on 29 August 2026.
Our evidence standard
Where four familiar numbers stop
5x faster
No source to follow
It sits on the page selling the service, with no study named, no baseline, no sample and no method. A second search found no publication behind the figure.
eleken.co/design-system-service fetched 29 August 2026Create designs 5x faster
50% efficiency gains
A case study of its own system
It links to a case study of that same design system, with no baseline, no sample and no method disclosed. The figure is the seller's own, about its own product.
netguru.com/clients/silk-design-system fetched 29 August 2026rapid prototyping completed 50% faster than before
475% ROI
Commissioned, and now unreachable
InVision's own page calls it a commissioned ROI study by Forrester Consulting, and Forrester states every Total Economic Impact study is commissioned. The study is unreachable now that every InVision URL redirects to miro.com.
InVision Total Economic Impact page, read through the archive traced 29 August 2026a commissioned ROI study conducted by Forrester Consulting
30-40% of development costs
Attributed to McKinsey, with no link
Identical wording on more than one agency blog. The nearest real study, read through the Internet Archive in a snapshot taken 14 January 2025, states its own method, and the phrase design system does not appear.
McKinsey design study, Internet Archive snapshot snapshot 14 January 2025300 publicly listed companies, five years, more than two million pieces of financial data
We print none of them. We tell you what it costs to build and to maintain, and show what we measured on your own codebase. Ask us for the change contract.
The two that can still be opened: Eleken's design system service page, Netguru's Silk design system case study.
How big is a design system, actually?
A component library is the built pieces themselves: the button, the form field, the table. The design system is that library plus the rules and documentation for using it. Most pieces carry variants, meaning one component with switchable options, so a primary button and a quiet button are one thing set differently.
Show data table
| Item | components published on the system's own index |
|---|---|
| GitHub Primer | 62 |
| Atlassian | 59 |
| Shopify Polaris | 47 |
| USWDS | 47 |
| Microsoft Fluent 2 | 47 |
| IBM Carbon | 40 |
| Material Design 3 | 36 |
Hold any proposal against that. A quote describing two hundred components is describing something other than a design system.
Source: GitHub Primer's own component index.
A core team works only on your project, with a lead software engineer you talk to directly.
What exactly do I get?
01
The change contract
What counts as a patch, a minor and a breaking change, written down for your codebase up front.
You get
The notice period for removing a component, agreed with you, plus the rollback path and who answers when a release breaks your build.
02
Tokens
A design token is a named setting, like brand blue or body text size, stored once for every screen.
You get
You get that file, plus theming: changing the look everywhere at once by swapping settings, for a dark mode or a second brand.
03
Components
The set your product needs, each one carrying a published status you can read before you use it.
You get
Each ships a stable selector, a permanent name so your tests and analytics keep working after an update. Primer's own decision record says why.
04
Accessibility built in
We build frontends that meet WCAG 2.2 by default, and higher conformance targets are supported on request.
You get
WCAG 2.2, published by the W3C on 12 December 2024, is the standard every component here is built to.
05
Documentation and handover
Documentation starts on Day 1 and stays current: architecture, deployment, the automated build and release pipelines, requirement documents and every change note.
You get
You end with an upgrade runbook and recorded training sessions that your own team can replay whenever they need.
WCAG 2.2 sets a contrast ratio of 4.5 to 1 for normal text and 3 to 1 for large text at 18pt or 14pt bold.
Sources: WCAG 2.2 at the W3C, Primer's stable selectors decision record (adr-023).
What does this cost, and what after you leave?
We have no published price and we will not invent a band.
Where you are starting
Two situations start this: nothing built yet, or a design file in Figma and a code library that already disagree. Either way we open by reading what is there, as part of requirements discovery and specifications, before anything is replaced.Two engagement shapes
Execution starts after you have approved the full scope. With a flexible budget or an urgent timeline, we start on the milestones already clear while the rest is refined.What moves the number
How many components your product needs, against that published median of 47. How many platforms you ship to. Whether an existing design file and code library must be reconciled rather than started clean, the biggest single swing. And your accessibility target.When scope changes
Every change request becomes a change note: the time, the effort and the cost laid out before approval. It enters the plan only once you sign off, confirmed in a meeting and in writing. The estimate is real then.What the form produces
Of the eleven competitor service pages we read on 29 August 2026, none publishes a price and one publishes durations. Writing in starts a conversation, not a quote.What happens when we are gone?
You leave and nobody here can maintain it.
Our rule as a vendor is to empower the client rather than lock them in.
What we commit to
Every line of code is your IP from the first commit. If you have your own Git hosting, cloud accounts and storage, we work inside them. If not, we set them up and hand you the keys.
Moving this to another partner turns into a negotiation.
What we commit to
If you move the work in-house or to another partner, you get a written runbook rather than a negotiation. So far no client has needed it, and it gets written anyway, at the start.
Nobody has decided who owns the system after handover.
Governance is the written answer to what you do when the thing you need is not in there.
What we commit to
Governance is agreed at intake: who decides, how you ask, how long it takes. We build toward a handoff to your own team if that is your direction, or stay as long as the platform needs us.
You have not shipped work like this before.
No design-system client is named here, because case proof of this kind is always anonymised.
What we commit to
50 or more enterprise engagements across 7 countries, 35 or more strategic projects delivered globally, and a longest active engagement running more than a decade. The shape of that work is in our case studies.
When Shopify retired the Polaris React library, it published the deprecation itself, named the replacement, and linked the archived documentation in the same notice. The npm record still carries that deprecated field on version 13.9.5, 26 March 2025.
Sources: the npm record for @shopify/polaris, the GitHub API record for Shopify/polaris.
Is this the right work?
Where we fit
Two or more products, or a second platform coming, with screens that already disagree.
A system that already exists and is not being adopted, where nobody has written down who changes it.
Adoption is the harder half. An adoption metric means the share of your product actually built from the system, counted rather than guessed, and we plan for partial rollout from the start.
Where we are the wrong call
One surface, one team, no second platform: a shared token file and a component folder will hold another year, and governance is not yet your problem.
What is needed is research and flows, not shared parts, because the open question is what the screens should do.
An audit or a remediation against a named standard, on a product that already exists, is faster as its own piece of work.
Questions we get asked
How will I know if anyone is actually using it?
Do I need to hire someone to keep this running?
Why can't we just use Bootstrap or Material?
What is your policy when a change breaks our build?
- You get a written change contract at the start of the engagement: what counts as a patch, a minor and a breaking change in your specific codebase, including the boundary cases such as a prop being deprecated, a prop type being widened, or the element an aria-label points at being moved.
- The notice period for removing a component is agreed with you and written into that contract before the first component ships, together with the rollback path and who answers.
How do I override a component when your default is wrong for my screen?
What do I do when the component I need does not exist?
Ask us for the change contract
Send us the product, roughly how many screens, whether there is a design file, and what broke last.
Ask for it and a technical person joins within one business day to answer architecture and stack questions directly.
Two outcomes are good: the conversation leads to work, or we say plainly that it should not and point you at what would help. The form will not give you a price without seeing what you already have.
- a reply within one business day
- your IP from Day 1
- a software engineer on request