Do You Really Need a Design System for Your Website or App?

Design systems have become the default recommendation in frontend development conversations. Articles describe them as essential infrastructure. Job postings list design system experience as a prerequisite. Conference talks treat them as table stakes for any serious product team.

But most of the teams being advised to build design systems are not Google, Shopify, or Airbnb. They are 5-person startups, small agencies maintaining a handful of client projects, or internal tools teams with two frontend developers. The advice being applied to them was built for organizations with dozens of designers and hundreds of components that need to stay consistent across multiple product surfaces.

Honest answer: a full design system is not what most of these teams need. What they need is usually much simpler, and understanding that distinction saves months of wasted effort and maintains development velocity during a period when shipping matters more than infrastructure.

What a Full Design System Actually Involves

When organizations like Atlassian, IBM, or Microsoft publish their design systems, the scope reflects their scale:

  • Hundreds of documented components with formal versioning and deprecation processes
  • A published npm package with a dedicated maintenance team and regular release cadence
  • A separate website or portal for documentation, maintained by technical writers
  • Governance processes for proposing, reviewing, approving, and deprecating components
  • Tooling for tracking adoption rates across multiple products and teams
  • Designers, engineers, and writers whose full-time responsibility is the system itself

This infrastructure exists because those organizations have dozens of product teams building on the same component foundation. The maintenance cost of running a formal design system is distributed across enough consumers to justify the investment.

For a team of five people building one product, this architecture is not only unnecessary - it actively slows you down. You end up spending time on governance processes, versioning decisions, and adoption tracking that have no practical value at your scale. The overhead of maintaining a formal system consumes engineering time that should be going to the product.

What You Actually Need for 80% of Use Cases

For most projects - websites, web applications, internal tools, client projects - the practical requirement is much simpler:

A design token file. Colors, spacing values, typography sizes, and border radius values defined as CSS custom properties in one centralized file. When a visual decision needs to change, you change it in one place and every component that references the token updates automatically. This setup takes a few hours and pays off immediately.

A small set of documented shared components. Five to ten of the most frequently used UI elements: a button, a form input, a card, a modal dialog, a navigation component. Each defined once, with its variants documented in a README or simple component demo. Not comprehensive. Just enough that a new developer knows where to look before building something new.

A consistent naming and file structure convention. Components that only appear in one context do not need to be in the shared library. They need a predictable location and clear names. The shared library is specifically for elements that repeat across multiple screens or features.

That is the practical requirement. No npm package. No dedicated documentation portal. No governance committee. Just a token file, a handful of well-documented components, and clear conventions that the team follows.

"Most small projects do not need a full design system on day one. They need a tokens file and two or three documented components. That is often enough to build consistently for years." - Dennis Traina, 137Foundry

When a Full Design System Is Justified

Investing in the full infrastructure makes sense when specific conditions are met:

Multiple teams build on the same components. If three feature teams are independently implementing buttons, forms, and modal dialogs, the duplication cost becomes significant. A shared system with formal versioning and published tooling becomes a productivity investment rather than an overhead.

Your product has a UI surface large enough to create maintenance complexity. A 200-screen application with dozens of component variants and multiple user roles has complexity that benefits from formal governance. A 20-screen application does not.

You have dedicated resources to maintain the system. A design system without an owner decays quickly. Component documentation falls out of date. Design tokens drift from the actual values in production. Deprecated components remain in use. If you cannot commit engineering time specifically to maintaining the system, a simpler informal approach will serve you better over the long term.

You are building a platform that others extend. If your application exposes a component library for third parties, or if you are building a platform where multiple products are built on a shared foundation, formalization is necessary for external consumers who cannot simply read the source code.

The Hidden Cost of Over-Building

There is a real cost to building design system infrastructure before you need it. Engineering time spent on versioning schemes, deprecation processes, and adoption tracking is time not spent building features. For early-stage products, this can meaningfully affect momentum.

There is also a maintenance cost that compounds over time. Documentation that no one reads still needs to be written and updated. Component governance processes still require developer attention for proposals and reviews. A formal system that is too large for its consumer base becomes a burden rather than an asset.

The teams that get the most value from design systems are the ones that scale their investment proportionally. They start with a token file and a few shared components, validate that the patterns work for their team, and expand the system only as the actual pain points justify it.

Where Custom Development Adds Value

Even if you do not need a formal design system, the technical foundations that make one work are valuable at almost any project scale. Design tokens reduce the cost of visual changes. Shared components reduce the duplication that causes visual regressions. Documentation reduces the onboarding overhead for new developers.

These three things deliver meaningful returns even on a project too small to justify a formal system. The question is always about scope and formality, not about whether the principles are worth applying.

For teams that are unsure where the line is for their specific project, 137Foundry works with engineering teams on exactly this kind of front-end architecture scoping. Their guide on building a design system for websites and apps covers an incremental approach that works across team sizes.

A Practical Recommendation by Team Size

Solo developer or freelancer: A CSS token file and one component per major UI pattern. No formal library needed. Focus on consistent naming and a predictable file structure.

Small team (2-8 people), single product: Token file, five to ten documented shared components, Storybook or a simple demo page. No formal governance yet. Assign one developer as the informal owner.

Mid-size team (10-30 people), multiple feature areas: A more structured component library with semantic versioning, a component catalog that is actively maintained, and clear ownership. Governance can remain lightweight.

Large team, multiple products or consumers: A formal design system with dedicated resources, published tooling, versioning, governance processes, and documentation infrastructure.

The mistake that slows teams down is applying the large-team answer to the small-team situation. Build what your team actually needs to move faster and maintain consistency. Let the system grow as the team, product, and actual pain points justify it.

Overbuilding design infrastructure before you have the use cases to validate it is as costly as having no system at all. The right investment is proportional to the maintenance and consistency problems you are experiencing right now, not the ones you might face in two years.

Comments

Post a Comment

Popular posts from this blog

Why ETL Pipeline Design Decisions Made Today Become Tomorrow's Technical Debt

Image
Data pipelines accumulate technical debt faster than almost any other category of software. The reason isn't complexity - most pipelines are structurally simple. It's that they're written to solve an immediate problem (move this data from here to there) without accounting for how requirements will change, how systems will evolve, and how the people who maintain the pipeline will need to understand and modify it months later. This piece is about the design decisions at the beginning of a pipeline project that determine whether it stays maintainable or becomes a liability. The "Quick Script" Problem Most pipeline technical debt starts with a script that wasn't supposed to last. A developer spends a day connecting two systems, it works, and it gets put in production. Six months later, the original developer is gone, the script has no documentation, it runs on a server that nobody is sure about, and changing anything requires reading the code and hoping you und...
Read more

How to Build Idempotent Webhook Event Processors

Image
Webhook delivery is at-least-once. If your endpoint returns a non-2xx response, the sender will retry. If there's a network timeout during delivery, the sender may retry even after a successful delivery that never reached you. This means your event processor must be idempotent: processing the same event twice must produce the same result as processing it once. Idempotency is not a nice-to-have. It's the fundamental contract that makes webhook integrations reliable. Without it, retry delivery creates duplicate records, double-charged accounts, and duplicate notifications. The Core Idempotency Pattern The standard pattern is event ID tracking. Every webhook sender includes a unique identifier in the payload. Before doing any processing work, check whether you've already processed this ID. If yes, return success and stop. If no, process the event and record the ID as handled. async def process_webhook_event(event_id: str, payload: dict) -> None: async with db.transa...
Read more

Why INP Replaced FID and What That Means for Your Site's Performance Score

Image
In March 2024, Google replaced First Input Delay (FID) with Interaction to Next Paint (INP) as the responsiveness metric in the Core Web Vitals set. This wasn't a minor update to thresholds or methodology. It was a fundamental change in what Google measures when it evaluates whether a page is responsive to users. If your site's responsiveness score looked fine under FID but has declined since the transition to INP, you're not alone. INP is a stricter metric that captures failures FID was structurally unable to detect. Understanding why the change happened and what INP actually measures is necessary context for fixing it. Why FID Was Limited FID measured the delay between a user's first interaction with a page (usually a click or tap) and the point at which the browser began processing the event. It captured only the delay before processing started, not the time required to complete the processing or render the visual response. This meant FID could look good even on ...
Read more