The design system pitch is a hard sell in most organisations. The cost is immediate and visible — weeks of design and engineering time building components that already exist in some form across the codebase. The benefit is diffuse and deferred — faster future development, fewer inconsistencies, reduced QA cycles. When a business is under delivery pressure, the immediate cost always beats the deferred benefit.
The calculation most teams skip
Count the number of times your team has built a modal, a date picker, or a data table from scratch. Multiply by the average engineering hours. That number — the accumulated cost of inconsistent, undocumented UI patterns — is your baseline. A design system doesn't add cost. It eliminates a recurring one.
What makes a design system actually get used
The design systems that fail do so for one reason: they're built by designers for designers, and engineers treat them as a constraint rather than a productivity tool. The systems that succeed are built with engineers from day one. Tokens are defined to map directly to CSS variables. Components are published to a package registry that engineers can install and update. The system lives where engineers work, not in a Figma file nobody has bookmarked.
The metric that makes the case
Track time-to-implementation for new UI features before and after your design system. In every organisation we've worked with, the before/after delta is between 40% and 65% reduction in frontend development time for features that reuse system components. That number, multiplied by your average engineering hourly cost, is your ROI. Present that number and the conversation changes.