October 14, 2026 · Design systems · 5 min read

21 days to 14: how a solo designer won resources for a design system

I had no team and no budget for a design system. I had one task measured twice, a pitch to the CEO and CTO, and 6 hours a week as the result.

The hydroburner mark made of rough tree bark, on a black background

In 2020 I was the only product designer in a B2B/B2C SaaS team, and the company had no plan to hire a second one. The Figma UI kit I inherited did not match production. Frontend and QA were fine with that: components were styled on the fly, layouts were checked by eye, and inconsistency did not look like a blocker to them.

I wanted a design system. Nobody had asked for one. This is how I got the CEO and CTO to back it, and how adoption reached 100%.

Start with an audit, then a pilot

I went through the product screen by screen and built an inventory in Figma, with screenshots and notes. The frequency of use set the priority, so the first components went to what slowed the frontend down the most.

Button audit spreadsheet: the variations of one control found in production — A sample of the button audit

A textbook rollout freezes feature work, and as the sole designer I could not afford that. Every new feature became a pilot instead. I built components inside active tasks and checked them under real conditions. I also synced with the frontend lead to agree on names for components and interactive states.

The pitch: one task, measured twice

In late 2020 I presented the results at a leadership sync. One task had taken about 21 business days before the system. The same kind of task on the new components took about 14 days.

Two bars: about 21 business days for the task before the design system, about 14 days on the new components — Simplified illustration of the measurement, not the pitch slide: the same task twice

The CEO approved the roadmap because the metric was clear and it translated into cost. The CTO backed the architecture: colors, type styles and Storybook alignment, with Figma and Storybook as the single source of truth. I got 6 hours a week officially allocated to the system.

The ask was small: 6 hours a week, no new people, no pause in the product. The evidence was already in production.

Engineering and QA needed their own argument

The CEO was convinced by the numbers. Frontend and QA needed to see it on real features, and a slide would not have done that.

For developers, the system meant pre-built components instead of custom CSS for every view. For QA it meant fewer pixel-level layout audits. The frontend lead became the main champion of the system in his team, and consistency as a baseline for UX became a shared goal.

After launch I drove adoption through design reviews of builds before they went to QA.

A design review before QA: the Figma layout, the staging build with two numbered mismatches, and a checklist where spacing and radius fail — A design review of a build before QA. A schematic: the real files are under NDA

In the end the system serves 4 frontend developers, 4 designers and 3 QA engineers. Time-to-market is about 30% shorter, and the team saves about 100 engineering hours a month on UI assembly. Over 5 years that is 6,000+ developer hours, not counting design and QA.

The pitch in five moves

This is the order I would use again.

Measure one real task twice. Pick a task the business already knows, a feature of average size, run it once the old way and once on your components, and compare delivery time. Days get approved, a percentage of consistency does not.
Pilot inside live work. A side project has no numbers because nobody uses it. A pilot inside a feature produces them and does not block the roadmap.
Ask for hours. I asked for 6 hours a week. It is easy to say yes to, easy to review in a quarter, and it can grow after the first result.
Prepare a separate argument for each person in the room: cost for the CEO, architecture for the CTO, less custom CSS for developers, fewer layout audits for QA.
Find the champion in engineering before the meeting. I had synced names with the frontend lead before I pitched.

My roadmap had five steps: baseline, core components, key patterns, alignment with code, documentation. The decision came from 21 versus 14.

What changed with Claude Code

By 2023 and 2024 the system had cut time-to-market by about 30%, and it took years of work to get there. Today the same result comes much faster. With Claude Code I can open Figma and build a design system dozens of times faster than before. I write the rules and review everything by hand. What took half a year can take about a week.

Two bars on one scale: half a year for a design system built solo inside live features, and about 1 week with Claude Code, where I write the rules and review the result — The same scope, two ways. A schematic of the order of magnitude, not a measurement

The pitch does not change: measure one task twice and ask for hours. The numbers just arrive sooner, so the conversation with the CEO and CTO can happen in the second week and not in the second year.