Does a five-person team actually need a design system

A full design system, tokens, documented components, a shared library between design and code, is genuinely valuable for a team of thirty designers and engineers shipping in parallel across a large product surface. For a five-person team, that same system can be overhead disguised as best practice, and we say so directly when a client asks for one prematurely.

The right question isn't how many people are on the team, it's how often inconsistency is actually costing time or credibility right now. If two designers are building similar screens with slightly different button styles and nobody's noticed a real problem from it, a design system solves a problem you don't have yet.

We ask clients to point to a specific recent incident, a bug caused by inconsistent components, a customer complaint about visual inconsistency, before agreeing a full system is worth building. Absent a specific incident, the request is usually driven by what a design system signals rather than what it actually solves.

There's a real signaling pressure behind these requests worth naming directly. A design system reads as a mark of a mature, well-run product organization, and founders sometimes want one for that reputation as much as for any functional need. We don't think that motivation is dishonest, but we do think it's worth separating from the functional question before committing real budget to solving a problem that's more about appearances than about anything actually slowing the team down.

Before a full system, most small teams get more value from a shared color and type scale, a small set of reusable components in Figma, and a one-page style guide that a new hire can read in ten minutes. That lightweight version captures most of the consistency benefit without the ongoing maintenance burden of a full token-based system nobody has time to keep updated.

We usually build this lightweight version in a day or two, directly inside the client's existing Figma file rather than as a separate document nobody opens. The goal is something a designer actually reaches for mid-task, not a reference buried in a shared drive that gets consulted once at kickoff and never again. A style guide that isn't actually open on someone's second monitor during real work isn't doing its job, regardless of how thorough it looks.

The signal we actually watch for: the team is about to double, multiple people will be building UI in parallel, or the product is expanding into a second platform (web plus mobile app) where consistency actually needs enforcing across codebases, not just visual review. That's when the investment pays back quickly instead of sitting unused.

We also watch for a subtler signal: a client starts asking the same question repeatedly, in Slack, in design reviews, about whether a specific button style or spacing value is the "right" one. That repetition is a sign the lightweight guide has stopped being sufficient, not because it was wrong, but because the team has genuinely outgrown what a single page can enforce on its own without a more formal system backing it up.

A design system isn't a one-time build, it's an ongoing commitment: someone has to own it, update it as the product evolves, and enforce its use. A small team that builds a full system and then doesn't have capacity to maintain it ends up worse off than one that never built it, because the system silently drifts out of sync with the actual product and misleads anyone who trusts it.

More than once we've inherited a partially built design system, a handful of Figma components, an abandoned tokens file, that was started with good intentions and dropped once the team got busy. Cleaning that up and deciding whether to finish it or fully retire it in favor of the lightweight approach is its own small project, one that's avoidable by starting lightweight in the first place.

The pattern is almost always the same: an early hire with strong opinions starts the system, gets pulled onto a deadline before finishing it, and nobody else on the team has the context or the mandate to pick it back up. What's left is worse than no system at all, since new team members find it, assume it's current, and build against components that were never actually finished or adopted, quietly reintroducing the exact inconsistency the system was meant to prevent.

A lightweight style guide typically takes a few days to put together. A genuine, documented, token-based design system with component libraries in both design and code is closer to several weeks of dedicated work, plus ongoing maintenance. We lay out both numbers explicitly before a client commits, so the decision is made with real costs in view rather than based on which option sounds more professional.

Occasionally a client insists on the full system regardless of our recommendation, often for reasons outside the product itself, an upcoming fundraise, a board member's expectation. When that's the case, we still build it properly rather than half-heartedly, but we're explicit upfront about who on the client's team will own its maintenance once we're no longer the ones updating it, since an unmaintained full system is worse than no system at all.

Start with the lightweight version. Upgrade to a full system when you can point to a specific, recurring cost that the lightweight version isn't solving, not because a blog post (including this one) says you should have one.

That last part is worth stating plainly, because it cuts against our own incentive as the agency that would get paid to build the full system either way. We'd genuinely rather sell a client a two-day style guide now and a proper design system in a year when they've actually outgrown it, than sell them the bigger project today and watch it sit half-used while the smaller thing would have served them just as well.