Design systems: when a small business actually needs one

Design systems have become something of a default recommendation regardless of company size, which isn't always the right call. Building a full component library for a five-page marketing site is usually wasted effort. The question is at what point a business actually crosses the threshold where it starts paying for itself rather than just adding process overhead.

A single designer working alone can keep consistency in their head without a formal system. The moment a second designer, or a developer making design decisions independently, joins the process, undocumented consistency starts to drift. That's the actual signal, not company size or revenue, and it can happen at a five-person startup just as easily as a larger company.

A marketing site with a handful of page templates rarely needs more than a style guide. A product with dozens of screens and states, empty states, error states, loading states, hits inconsistency fast without a shared component library, because the same button or form field gets rebuilt slightly differently in a dozen places otherwise, and nobody notices until a user does.

For a team not ready for a full component library, we start with design tokens: a defined color palette, type scale, spacing system, all named and documented, even before every component exists. This gets most of the consistency benefit at a fraction of the build cost, and components can be layered on as they're actually needed rather than built speculatively upfront.

A design system that's built but not maintained becomes actively misleading, since developers start ignoring a component library everyone knows is out of date. We only recommend building one when there's a real commitment to keeping it current, which is as much a process question as a design one, and we say so directly when a client isn't ready for that ongoing commitment.

For teams in between, too big for no system, not ready for a full one, a simple Figma library with 15 to 20 core components covering buttons, forms, cards, and navigation elements, paired with the token documentation, covers most of the practical need without the overhead of a fully governed enterprise design system.

A client once asked us to build a comprehensive 40-component design system before their product had a single paying customer. We talked them into a much lighter token-based approach instead, since a full system built before real usage patterns exist tends to need significant rework once actual product needs become clear, wasting the upfront investment.

For a team of one or two developers, a design system's value comes primarily from reducing decisions, not from enforcing governance across a large team. We tailor the documentation depth accordingly: less process, more just a clear, fast reference a small team can build from quickly without a formal review step for every use.

This is the single most common failure mode we see: a system built once, then ignored as the product evolves, until developers stop trusting it entirely and start rebuilding components ad hoc again. Preventing this is more about assigning clear ownership than about the system's initial technical quality.

Before expanding an existing design system, we recommend auditing how many recently shipped features actually used it versus built something custom. A low usage rate is a sign the system doesn't cover real, current needs well enough yet, and expanding it blindly without addressing that gap will just produce more unused components.

Bringing in an outside freelancer or agency for a single project, a landing page for a campaign, for instance, risks introducing components that don't match the existing system if that contractor isn't given access to it. We provide a lightweight onboarding document specifically for external contributors so the system stays consistent even when work is happening outside the core team.

Full committee-based design system governance is overkill for a small team, but zero governance lets drift creep back in fast. A simple rule, any new component gets a quick five-minute review from the other designer before being added to the shared library, is usually enough structure for a team this size without becoming its own source of friction and delay.

Rather than discarding an inherited design system entirely, we audit what's genuinely working within it, and preserve those elements, replacing only what's inconsistent, poorly documented, or actively causing problems. A wholesale replacement is disruptive and often unnecessary; a targeted improvement respects the real investment already made while still fixing what's actually broken.

We also help clients think about design system investment in phases explicitly tied to team growth milestones, rather than as a single all-or-nothing decision made once. A documented plan, for instance moving from tokens-only to a full component library once the design team grows past two people, gives a client a clear, low-pressure roadmap to reference later, rather than facing the tokens-versus-full-system decision again from scratch each time their actual team and needs have meaningfully changed.

We look at two practical signals: how much time a new screen or feature takes to design and build now compared to before the system existed, and how often developers report needing to ask a designer a clarifying question about a component that already exists in the library. Both numbers moving in the right direction, faster builds, fewer clarifying questions, is a much better indicator of real value than a subjective sense that things feel more organized.

When those numbers aren't improving even months after a system is in place, that's usually a signal the system itself has a usability problem, poor documentation, missing edge cases, components that don't map cleanly to real screens, rather than a signal that design systems in general don't work for this team. We treat that as a prompt to revisit the system's structure, not a reason to abandon the idea of having one at all.

Pre-built component libraries can genuinely shortcut the early stages of this work, and we'll recommend one when a client's needs are close enough to what it already covers. The catch is that heavy customization to match a specific brand can end up costing nearly as much as building a lighter custom system from scratch, so we evaluate the actual gap between the off-the-shelf option and the client's real requirements before recommending either path.