Phase 3: Design

In one line: Figma plus a design system. Designers and engineers collaborate closely and share a component library — usually shadcn/ui at first.

In plain English

At solo scale, "design" might be a few rectangles on paper. At startup scale, you have a designer (or several) producing real Figma files, and a shared design system that translates those files into code. The whole goal is to keep the gap between "what's in Figma" and "what's in production" small enough that designers can trust what they see in staging.

How designers work

Designers work in Figma. They use the company's design system (a set of reusable components and tokens).

Engineering–design collaboration

Engineering and design collaborate closely:

• Engineers attend design reviews to flag feasibility issues early.
• Designers attend stand-ups to stay synced.
• Both use shadcn/ui or a custom design system in code.

Design system maturity at this stage

• 5–10 people: Use shadcn/ui directly. Customize colors and typography to match brand.
• 10–25 people: Maintain a small private component library extending shadcn.
• 25–50 people: Full design system in Storybook, with a designer-engineer owner.

Worked example: the design-feasibility loop

A designer mocks up a new dashboard with a fancy sticky filter panel. In design review, an engineer notices: "We render this server-side, so the sticky panel has to be a Client Component, which means we ship JS for the filter logic." They propose: either accept the JS cost, or make the panel non-sticky and ship purely server-rendered.

Both options get sketched. The designer picks "non-sticky, server-rendered" because performance matters more than the visual flourish here. Decision made in five minutes — because the engineer was in the room.

Without that feedback loop, the team would have built the sticky version, discovered the cost mid-implementation, and either shipped a slower page or thrown away two days of design work.

Highlight: shadcn/ui is the default for a reason

At 5–10 people, you don't have time to build a design system. shadcn/ui gives you a fully-styled, accessible component library you own (the components live in your repo, not as a dependency). You customize colors, typography, and edge cases as needed.

As you grow, you wrap shadcn components in your own primitives, then eventually graduate to a fully owned design system in Storybook. But the path from "no design system" to "full Storybook" goes through shadcn — not around it.

Common mistakes

Where people commonly trip up

• Forking shadcn into a "custom design system" at 8 engineers. You don't have the throughput to own a real component library yet. Customize tokens, customize specific components when you must, but resist the urge to rename everything and turn it into "your" system before there's a designer-engineer pairing to own it.
• Skipping engineering review on Figma files. You ship the mock, then discover halfway through implementation that the gradient requires a Client Component or the chart library can't render that shape. Five minutes of "is this feasible?" before designs go to engineers saves days.
• Treating Figma fidelity as the acceptance criterion. Pixel-perfect is the wrong goal at this stage. The right goal is "the experience matches the intent" — which sometimes means ignoring 4px of padding to save a day of engineering work.
• Hiring a second designer before the first one has a design system to point to. Two designers without a shared library produce two visual languages. Lock the foundation (tokens, primitives, common patterns) before adding the next seat.
• Letting design debt grow invisibly. Engineers route around the design system with one-off components when shadcn doesn't fit. Without a quarterly audit, you wake up with 14 button variants. Track exceptions explicitly.

Page checkpoint

Checkpoint Quiz

Did startup-scale design stick?

Required

What's next

→ Continue to Phase 4: Architecture where the modular monolith and the 2026 stack come together.