So I built a design system anyway. Not the kind you’d see presented at a conference. No elaborate documentation site, no versioning strategy, no governance council. Just the kind that actually worked for three people trying to do the work of ten.

If you’re in a similar spot right now, here’s what I learned.

Start with what’s costing you time

Don’t try to build everything at once. Look at your last three projects. What did you redesign from scratch every time? What decisions did you re-make? Where did inconsistencies creep in without anyone noticing?

For me, it was buttons and form fields. I had four different button styles across three client sites. Every new project started with “what’s our button padding again?” So I standardized two button variants and three form field states. That was version one.

Find your version of that. Build those components first. Everything else can wait.

Documentation is just decisions written down

You don’t need Storybook. You don’t need a custom docs site. You don’t even need Notion if you don’t want it.

What you need is a single source of truth for the decisions you’ve already made. When should this button be primary vs. secondary? What’s the minimum tap target size? Do we allow icon-only buttons, and if so, where?

I kept mine in a Figma file with a page called “How we use this.” It was just text boxes next to components. When to use it. When not to use it. Edge cases I’d already encountered. If someone asked a question more than once, the answer went in the doc.

The goal isn’t completeness. It’s clarity. If your team can look at the system and make a decision without asking you, it’s working.

Build components, not pages

This one’s subtle but important. A design system isn’t a template library. It’s not “here’s our pricing page layout” or “here’s how we do hero sections.” That’s too specific. It breaks the moment your next project doesn’t fit the mold.

Instead, build the pieces that combine into pages. A card component that works in a grid. A section heading treatment that scales. A CTA block that’s flexible enough to work in three different contexts.

The more composable your system, the less you have to maintain. And when you’re a team of three, maintenance cost is everything.

Let it grow slowly

A design system for a small team shouldn’t be a capital-P Project. It should be a living artifact that grows as you work.

Every time you design something new, ask: “Is this a one-off, or will we need this again?” If it’s the latter, pull it into the system. Clean it up. Document the decision. Move on.

This is how my system went from two buttons to a workable set of components over six months. I didn’t block out two weeks to “build the design system.” I just kept adding to it as I worked.

Some months I added nothing. Some months I added three new components. It didn’t matter. The system grew at the pace of actual needs, which meant it stayed useful instead of becoming a dusty artifact no one touched.

Don’t design for scale you don’t have

Here’s the thing about design systems: the advice you’ll find online is written by people at companies with twenty designers. They have component APIs. They have design tokens synced to code. They have automated visual regression tests.

You have three people and not enough hours in the day.

That’s fine. You don’t need their system. You need yours.

For me, that meant: Figma components, yes. A shared color palette and type scale, yes. Coded components in our project repos, eventually. A design token pipeline? No. A staging environment for the design system? No. A Slack channel just for system updates? Definitely not.

I kept it as simple as I could while still solving the problem. When the team got bigger, I added complexity. Not before.

The system is a tool, not the work

The point of a design system isn’t the system itself. It’s what the system lets you do.

If you’re spending more time maintaining the system than it’s saving you, something’s wrong. If you’re debating whether a new component “belongs” in the system instead of shipping work, something’s wrong. If the system is making decisions slower instead of faster, something’s wrong.

A design system for a small team should fade into the background. It should make the work easier, not add ceremony. The moment it stops serving you, cut it back.

What I got right (and what I’d do differently)

Looking back, here’s what worked:

• Starting small and growing slowly meant the team actually used it

• Documenting decisions, not just designs, saved us from re-debating the same things

• Keeping it in the tools we already used (Figma, our repos) meant no extra overhead

What I’d do differently:

• I’d involve the developers earlier. I treated it as a design artifact for too long, and that made handoff messier than it needed to be

• I’d name things better from the start. I had a button called “secondary-alt” that no one could ever remember the purpose of

• I’d resist the urge to over-build. I spent time on components we used once and never touched again

You don’t need permission to start

If you’re waiting for the right moment, more resources, or buy-in from someone above you, stop. A design system for a small team doesn’t need a project plan or a budget. It just needs someone willing to write down the decisions you’re already making.

Start with one component. Document why it works the way it does. Use it in your next project. Add another when you need it.

That’s it. That’s the system.

You don’t need to build the whole thing today. You just need to start building the thing that makes tomorrow easier.​​​​​​​​​​​​​​​​