Building a design system from zero in 6 weeks: a startup playbook

A founder reached out late last year with a problem that's becoming common: "We've shipped 8 features in 6 months. They all look like different products. Help."

The fix everyone reaches for is "we need a design system." Then six weeks of meetings happen, a Notion doc fills up with token names, and nothing ships. The eng team goes back to coding, and the next feature looks like the seventh different product.

Here's a more direct path. I've done this at a few companies now — most recently a Series A engagement with Hafnova where we went from zero system to a working v1 in six weeks. Here's what's actually load-bearing.

Week 0: Audit, don't design

Before you decide what the system should be, spend a week mapping what already exists. Open every page of the product. Take screenshots. Annotate every input, button, modal, table. The goal is to see how many of each pattern you actually have today.

You'll find absurd numbers. One team I worked with had 14 different button styles and 9 different modal heights. Until you can see the inventory, every design system conversation is theoretical.

This week is also when you decide what not to design. If you have one rarely-used component (a complex multi-select used on three screens), it doesn't go in v1. The system should cover ~80% of usage. The long tail can stay one-off.

Week 1-2: Foundations only

Most teams over-engineer foundations. Tokens for everything. Color scales of 9 stops. Spacing scales of 16 values. Typographic systems with display, headline, title, subtitle, body, caption, micro, lead, lead-emphasis...

Don't.

A working v1 needs:

• Color: 6-8 semantic tokens — fg, fg-muted, fg-subtle, bg, bg-elevated, border, border-strong, accent. That's it.
• Spacing: 6-8 values on a 4 or 8 multiplier. Name them by size, not by purpose.
• Type: 3-4 sizes — display, h1, body, caption. Each with one line-height. Skip body-lg / body-xl until you've shipped.
• Radius: 3-4 values. None, sm, md, lg.
• Shadows: 2 values. Subtle, prominent. You'll add a third later if needed.

These foundations are 90% of what governs whether the product feels cohesive. The other 10% is consistency — which comes from components, not tokens.

Week 3-4: Components, ranked by impact

There are 15-20 components in any product UI. They are not equal. Prioritize by which ones, when fixed, fix the most surface area.

The order I use:

1. Button — appears everywhere. Even small inconsistencies feel cheap.
2. Input — same. If your inputs are slightly different across forms, the whole product feels off.
3. Card — sets the visual language for content groupings. Get this right and 50% of new pages look fine by default.
4. Modal/Dialog — high visibility, often the most janky.
5. Navigation — header, sidebar, bottom tabs depending on product. The hardest because it touches every page.
6. Table — if your product has data, this is where the visual debt lives.

The rest (badges, avatars, tooltips, dropdowns) come after. They're refinement, not foundation.

For each component, ship two variants max in v1. A button has primary and secondary. An input has default and error. Adding a third variant requires evidence — not preference.

I wrote about the broader process I run with founders — design systems are an extreme version of that process: the work is upstream of the screens.

Week 5: Refactor real screens

This is where most design systems go to die. The components exist in Figma. The team applauds. Nothing in the actual product changes.

Force a refactor sprint in week 5. Pick the three most-visited pages of the product. Rebuild them on the new components. Audit what breaks — there's always something the system didn't account for.

The breaks are the gold. They reveal which patterns your audit missed. Fix the system to handle them. Don't fork the components for "this one screen."

Week 6: Governance, lightly

The biggest mistake at this stage is over-formalizing the system. RFC processes. Design review boards. Component status indicators with five tiers.

A 5-person company doesn't need any of that. They need a slack channel called #design-system, a single document that says "ask before adding new patterns; reuse first," and one person (you) as the keeper.

When the company doubles in size, you'll know what governance looks like for them. Not before.

What to skip in v1

Things I see teams obsess over that you can defer:

• Dark mode. Unless your product is used at night (terminals, dev tools), this is a 10x return on investment to add, not a launch requirement. v2.
• Documentation site. A Storybook with components and a Figma library is enough for v1. A pretty docs site is satisfying to build and customers don't care.
• Token sync between Figma and code. Manual is fine at fewer than 10 designers and engineers combined. Automation costs more than the inconsistency it prevents.
• Cross-platform tokens (web + mobile + email). One platform first. Get it shipping. Cross-platform is a v3 problem.
• Animation system. Unless animation is core to your product, generic transitions (200-300ms ease-out) are fine.

This list is shorter than what you're being told online. That's intentional.

What "shipped" looks like

A v1 design system is shipped when:

1. Three real product pages are running on it in production
2. The next feature shipped uses it without forking
3. There's a Figma library and component code in the same package
4. One non-design person (an engineer) has used it without asking for help

That's the bar. Not "complete coverage." Not "documentation perfection." Working.

For the Hafnova engagement, this whole sequence took about six weeks of focused work. The product team is still extending it 8 months later — which is the actual measure of whether the system was built right.

A note on tools

People ask me a lot which tools to use. The honest answer is it doesn't matter much at this stage. Figma + GitHub + a design-tokens-as-code package (Style Dictionary, Tokens Studio, or hand-rolled). Anything fancier is procrastination. I went deeper on the tool stack I actually use elsewhere.

The hardest part is restraint

If I had to compress this into one rule: a design system is a system of no's more than yes's. Every component you don't add is one less variant to maintain. Every variant you don't allow is one less inconsistency to fight later.

The teams that succeed at design systems early are the ones whose first version is embarrassingly small. The teams that fail are the ones who tried to predict every future need.

Build small. Refactor real screens. Stay restrained. Six weeks is enough.

If you're trying to start a design system from scratch and want to talk through the right scope for your stage, drop me a line — I've done this enough times that I can usually point you at the right shape of v1 for your team in a 30-minute conversation.