Design system implementation: when to build vs buy

Design system implementation is a product problem, not a design deliverable. The counterintuitive truth: shipping tokens and components is cheap; making them the driver of cross-team efficiency is where teams spend months and hundreds of thousands of dollars.

A 5-engineer UI team at a US startup represents roughly $900k/yr fully loaded (5 × $180k). A modest design-system v1 typically costs $80k–$300k to build and 0.5–1.0 FTE to maintain. Tooling and vendor subscriptions for documentation, component hosting, and visual testing run another $5k–$50k/yr. Adoption delivers measurable savings: most teams see 15–25% less UI rework over 18 months, which for a $900k team is $200k–$340k saved.

Direct answer: Should you build or buy design system implementation? If your UI spend exceeds $750k/yr, you support three or more platforms (web plus native), or your product differentiation depends on custom interaction patterns, build a carefully governed internal system; otherwise buy tooling plus a short consultancy engagement — total first-year cost typically $30k–$120k versus $120k–$420k to build and staff.

Design system implementation tradeoffs

Break the decision into three buckets: cost, differentiation, and operating model. Cost: a one-time build for v1 at $150k plus 0.5 FTE maintenance (~$90k/yr) yields a 3-year TCO of ~$420k. Buying a combination of Figma tokens tooling, Storybook/Chromatic hosting, and a consultancy engagement runs $40k–$120k/yr — 3-year TCO ~$180k–$360k depending on scale and vendor selection.

Differentiation: Shopify's Polaris and Stripe's internal systems exist because their UI patterns are product differentiation and developer experience assets. If your product relies on bespoke gestures, offline sync, or platform-specific animations, building keeps you from shoehorning solutions into generic components. If your interface follows common patterns (lists, tables, forms), commercial tooling accelerates delivery by 3–6 months on average.

Operating model: most failures happen after launch. Without CI enforcement, component library merges become optional and designers ship variants in Figma that never reach code. Teams that add gated checks in CI and require component usage in PRs see adoption rates jump from ~35% to 70% within six months. That governance cost is the multiplier — not the initial design tokens or Storybook pages.

Build when UI spend, platform count, or product differentiation justify a long-lived team; buy when you need velocity and can standardize on common interaction patterns.

What this means for your design tokens implementation

You must treat design tokens as a distributed artifact with SLAs. If your token repository is a Figma file and a ZIP download, adoption will be ad hoc. Invest in a tokens pipeline: a canonical source (Figma variables or design-tokens JSON), automated exports into platform-specific packages (CSS variables, Swift structs, Android resources), and a CI job that publishes releases. That pipeline typically costs 0.2–0.5 FTE to set up and $5k–$20k in initial tooling work.

Measure the right signals: percentage of new UIs using system components, average PR time saved, and component churn. Aim for 70% usage within six months and 30–40% reduction in visual regressions caught in manual QA after you enable visual testing. Track these metrics quarterly and tie them to sprint planning.

Checklist: when to build vs buy (quick decision)

1) Build if you meet two of these: >$750k/yr UI spend, 3+ platforms, or product-differentiating interactions. 2) Buy if you need launch velocity: teams <3 designers or <30 reusable components. 3) Always budget 0.5 FTE for governance, even when buying tooling. 4) Require CI gates for component releases and visual tests before any buy or build decision is final.

Operationally, if you choose to build, staff a 0.5–1.0 FTE design-system engineer and a product owner who can prioritize cross-team requests. If you buy, budget a 3–6 week consultancy engagement (~$15k–$60k) to integrate tooling, set up CI, and define contribution flows; without that integration, commercial tools rarely reach 50% adoption.

A final architectural trade-off: monorepo components with native wrappers (React + Swift + Kotlin) reduce mismatch and rework; the upfront cost is ~20–30% higher than maintaining separate repos but rework drops by roughly 30–40% over 12–18 months. If your roadmap includes frequent UI changes, the monorepo approach returns value fast.

Design system implementation succeeds when you treat it like a product: define SLAs, instrument adoption, and commit to governance. The technical choices — tokens pipeline, component hosting, visual testing — are cheap compared with the human coordination that makes them useful. Invest there first, and the dollars you spent on tooling pay for themselves in reduced rework and faster feature delivery.