Design Systems for Tiny Teams: How We Ship Consistent UI With Fewer Than Three People

Every design system article we read is written for teams of forty. Dedicated design ops, a Figma library with versioned releases, a components package published to a private registry, a governance committee. We are a studio where the same person who designs a screen also writes the migration for it. If we tried to run a "real" design system, we would spend our entire year maintaining the system and shipping nothing.

And yet we ship a lot of surface area. Our tools platform alone has grown past 248 free browser tools, plus a studio site, product micro-sites for seven games, and client work. All of it needs to look coherent, work in dark mode, and not embarrass us on an accessibility audit. So we have had to figure out which 20% of a design system actually earns its keep for a team of one to three people.

The short answer: standardize decisions, not pixels. A tiny team's design system is a small file of tokens, a borrowed component library you own outright, and three or four rules you refuse to break. Everything else is overhead dressed up as rigor.

Tokens before components, always

The first thing we standardize on any new project is not a button. It is the set of raw decisions a button is made from: color scale, spacing scale, radius scale, font stack, shadow levels. Written as CSS custom properties or a Tailwind theme, this is maybe 60 lines. It takes an afternoon. And it quietly makes every future screen consistent, because nobody is inventing a new gray or a new 13px gap at midnight.

Our rule of thumb: if two screens look different, 90% of the time it is a token violation, not a missing component. Someone used gray-400 where the muted-text token should have been, or 18px padding where the scale says 16 or 20. Fixing this at the token level means the fix is one line and it propagates everywhere. Fixing it at the component level means an audit.

Components, by contrast, are expensive to build and expensive to keep generic. A tiny team should build a component only after it has copy-pasted the same pattern three times. Before that, duplication is cheaper than premature abstraction — the pattern has not stabilized yet, and a wrongly-shaped component is worse than no component. Once we do extract, we keep it deliberately small: props for the variations we actually use today, not the variations we imagine a design system "should" support.

When to copy shadcn — and when not to

We copy shadcn/ui components into most React projects, and we recommend it to every small team we talk to. But it matters to understand what you are buying. shadcn is not a dependency; it is a starting point you own. The code lands in your repo, and from that moment it is yours to maintain, restyle and break.

That ownership model is exactly right for tiny teams. A traditional component library (MUI, Ant) gives you speed on day one and a fight on day ninety, when the design wants something the library's theming API does not allow. With copied components, day ninety is a normal edit.

• Copy shadcn for the fiddly, stateful primitives: dialogs, dropdowns, comboboxes, toasts, tooltips. These sit on Radix, and the keyboard handling and focus management alone represent weeks of work you should never redo.
• Do not copy it for things that are just styled divs: cards, page shells, hero sections, stat tiles. Write those yourself against your tokens — they are ten lines each, and copying them adds indirection without saving real work.
• Restyle everything you copy on arrival. If your product looks like default shadcn, you have skipped the actual design step, and users can tell.

The trap to avoid is treating copied components as a framework. When we bolt features onto a copied dialog, we edit our copy directly. We do not maintain a patch layer or try to stay "upgradeable" — the whole point of the model is that there is nothing to upgrade.

Dark mode from day one, not as a retrofit

We have retrofitted dark mode exactly once, on an early project, and it cost roughly two weeks of touching every file. Since then it is a day-one decision on everything we build, and it costs almost nothing — provided you did the tokens step.

The mechanism is simple: components never reference raw colors, only semantic tokens like background, surface, border, text, text-muted, accent. Dark mode is then one alternate set of token values, switched by a class on the root element and defaulted from prefers-color-scheme. When 248 tools all read from the same dozen semantic tokens, dark mode for a new tool is free. When even five components hard-code white backgrounds, you are on the two-week path.

Two dark-mode specifics we learned the hard way: pure black backgrounds with pure white text look harsh and cause halation for astigmatic users — we use very dark grays with slightly dimmed text instead. And shadows nearly disappear on dark surfaces, so elevation needs a second signal, usually a subtle lighter surface color or a border.

The accessibility baseline we never skip

We do not claim full WCAG audits on every side project. But there is a floor we treat as non-negotiable, because it is cheap when done early and each item is a lawsuit-grade or user-losing failure when skipped.

• Text contrast of at least 4.5:1 for body text and 3:1 for large text, in both themes. Checked when the token file is written, once, not per screen.
• Visible focus rings on every interactive element. Removing outline with no replacement is the single most common crime we see in small-team codebases.
• Full keyboard operability for anything with a click handler. This is mostly free if you use real buttons and links instead of divs — and it is precisely why we copy Radix-based primitives rather than writing our own dropdowns.
• Hit targets of at least 40 to 44px on touch, labels tied to inputs, and alt text on meaningful images.
• prefers-reduced-motion respected. We love heavy GSAP animation on our marketing surfaces, but every animated experience we ship has a reduced-motion path that simply cuts to the end state.

This list takes perhaps 5% extra effort during the build and is nearly impossible to bolt on cleanly afterward. It is also, bluntly, a competitive advantage: most tiny-team output fails half of it.

What to standardize first when you have one afternoon

If you are starting from zero, this is the order we would do it in, based on what has saved us the most rework across projects.

• Semantic color tokens, light and dark values together. One hour, highest leverage of anything on this list.
• A spacing and radius scale, and a rule to never use arbitrary values outside it.
• Typography: one font stack, five sizes, two weights. Constraint reads as polish.
• Focus, hover and disabled states defined once, globally.
• A page shell: max width, gutters, vertical rhythm. Most "this page feels off" complaints are actually shell inconsistencies.
• Buttons and form inputs — the only two components worth building before the rule of three kicks in, because they appear everywhere immediately.

Notice what is absent: no Figma library, no Storybook, no documentation site. For a team this size the codebase is the documentation, and grep is the component browser.

The payoff is speed, not beauty

The honest reason a tiny team should care about any of this is velocity. On Gigai Tools we can take a new tool from idea to live in under a day, and the majority of that speed comes from never making UI decisions twice: the harness, tokens and shared primitives mean a new tool — whether a JSON formatter or a QR code generator — is mostly its actual logic. Consistency is the visible result, but the real product of a small design system is that every decision you standardize is a decision you stop paying for.

So skip the governance model. Write the token file, steal the hard components, wire dark mode before the second screen exists, and hold the accessibility floor. That is the whole system — and for a team of three, it is enough to look like a team of thirty.