Design systems that earn their keep

Open your app and click through five screens. The button on the login page has a different radius than the button on the dashboard. The blue on the pricing page sits a shade off the blue in the nav. One form uses 16px labels, the next uses 14px. Nobody decided any of this. It just accumulated.

That's the flinch. A product that looks like five different apps wearing the same logo. Every screen reinvented the button because whoever built it couldn't find the last one, so they made a new one. Multiply that by a year of shipping and you've got a codebase where nothing agrees with anything.

A design system fixes the look. And it does the thing founders underrate: it makes every screen you build next faster. That's the part worth paying for.

What a design system actually buys you

Not a trophy. Not a 40-page file you flash at investors. Two things you can measure: speed and consistency.

Speed, because the next feature stops starting from zero. Your team reaches for a button that already exists, already handles focus states, already matches the brand. Consistency, because there's one button, one blue, one spacing scale, and every screen drinks from the same well.

Here's the split most people don't feel until they've lived both sides.

The system is a multiplier. You pay once, and every future screen collects the interest.

Tokens are the single source of truth

A token is a named decision. Not #2563eb scattered across 200 files. One name, color.brand.primary, that means this blue, everywhere it shows up.

Spacing, color, type scale, radius, shadow. Every visual choice becomes a variable with a name instead of a magic number copy-pasted until it drifts. When the CEO wants the brand blue a touch darker, you change the token. You don't go spelunking through the codebase praying you caught every stray hex.

One source of truth. Every screen agrees. That's the whole promise, and tokens are how you keep it.

Keep design and code in sync

Here's where most systems rot. The Figma file says one thing. The code says another. They drift apart inside a month, and now you've got two sources of truth, which is the same as having none.

My fix: tokens live in code. Typed. Shared. I'm a TypeScript-everywhere person, so the tokens are TypeScript too, which means the compiler enforces the system instead of a Slack reminder nobody reads.

export const tokens = {
  color: {
    brand: '#2563eb',
    ink: '#0f172a',
    muted: '#64748b',
  },
  space: [0, 4, 8, 12, 16, 24, 32, 48],
  radius: { sm: 6, md: 10, lg: 16 },
} as const;
 
type Space = (typeof tokens.space)[number]; // 0 | 4 | 8 | 12 | 16 ...

Now a teammate can't type space: 7. The editor won't let them. The system stops being a polite suggestion in a design doc and becomes a type error at 2pm instead of a visual bug in production. Design picks the values, code makes them impossible to break. More on why I bet everything on types in why I don't ship without TypeScript.

When a startup needs one, and when it's too early

I'll be straight with you, because pretending otherwise costs you money. Most pre-launch startups don't need a design system yet. Four screens and you're still figuring out if anyone wants the thing? A formal system is premature. You'd be sanding the frame before you know what the painting is.

Build the thing first. Find the shape of it. The signal that it's time shows up fast: you catch yourself copy-pasting a component and tweaking it, a second engineer joins and starts guessing your patterns, or "make the CTA green" turns into a two-day hunt. That's the moment. Not the sprint before it.

Nielsen Norman Group has a clear primer on what design systems are and when they pay off if you want the research-backed version.

The sales angle nobody connects

I spent twenty years selling before I wrote a line of code, so I read products the way a buyer does. And a buyer reads consistency as competence.

A prospect can't audit your architecture. They can't see your test coverage or your error handling. What they see is the surface. When every screen agrees, when the spacing breathes the same way and the buttons behave the same way, some quiet part of their brain files you under "these people have their act together." When the screens fight each other, that same part whispers "if the visible stuff is this sloppy, what about the stuff I can't see?"

Consistency reads as competence. Competence converts. A design system isn't decoration bolted on top of the product. It's the product looking like it earns the price on the invoice.

Frequently asked questions

Is a design system too early for my MVP?

Usually, yes. If you're still chasing product-market fit with a handful of screens, build the product and let the patterns show themselves. The system starts earning its keep once you're repeating yourself or adding people to the team, not before.

Figma first or code first?

Design decides the values in Figma. Code is where they become real and enforceable. If I had to name one home for the source of truth, it's code, because that's what ships to users. Figma stays in sync with the tokens, not the other way around.

Who maintains it once it exists?

Whoever ships UI. A system that needs a dedicated committee dies of its own overhead. Keep it small enough that adding a component is a ten-minute pull request, and it stays alive, because using it is easier than working around it.

How big does it need to be to start?

Smaller than you think. Color, spacing, type, and your five most-used components cover most of the screen. You grow it when a real repeated need shows up, not to fill out a checklist someone found online.

Build the boring part once

A design system is the least glamorous advantage you'll ever buy. No user ever tweeted about your spacing scale. And every fast release, every on-brand screen, every new hire who ships in their first week traces straight back to it. Get the tokens into code, typed and shared, and let the compiler hold the line so you don't have to. If you want one built that pays for itself instead of gathering dust in a Figma tab, here's the service, and tell me what you're building.