You Don't Need a Design System
Most teams shipping a design system are LARP-ing maturity. The maintenance cost outpaces the payoff, AI generation collapses the math, and a tokens plus primitives plus taste stack beats a fully-specced system for 95% of orgs.
You probably do not need a design system. You need a few design tokens, a small component library, and a person on the team with taste. The thing your favorite design Twitter account keeps posting about, the Figma file with 400 published components and 12 themes, is a full-time product that your eight-person startup is paying for and not collecting on.
This is the take everyone in the industry knows is true and nobody says out loud. The maintenance bill is real. The payoff is mostly imagined. AI generation just made the gap between the two worse.
The 95% of teams shipping a design system are LARP-ing maturity. The 5% who actually need one are usually not the teams asking the question.
A design system is a product, not a side quest
A real design system has its own roadmap, its own changelog, and its own customers. Those customers are the engineers and designers shipping the actual product. If nobody is staffed to maintain the system, it is not a system. It is a snapshot.
Look at who ships design systems well. Stripe has a dedicated design infra team. Shopify Polaris has its own org. GitHub Primer has a public repo with version releases.
Atlassian has years of investment in a system most teams will never approach in scope. Each one is a product team building tooling for an internal customer base that runs into the thousands.
Now look at the typical version. A senior designer spent six weeks in Figma, published 80 components, wrote a Notion page no engineer reads, and shipped two themes. Six months later, half the components are out of date, the tokens drift from the codebase, and the team is back to copying Tailwind classes. The system did not fail. The team failed to staff it.
The maintenance bill nobody puts in the slide deck
The payoff pitch goes: build it once, reuse it forever. The actual math: build it once, then maintain it forever, and reuse some of it sometimes.
Every design token that exists has to be kept in sync between Figma and code. Every component variant has to be tested when the framework upgrades. Every breaking change in Radix or React or Tailwind ripples through every dependent product. Documentation rots within a quarter.
The Storybook instance breaks on a dependency bump and nobody notices for three weeks. The published Figma library lags the codebase by a release. The themes diverge. The components in the system are not the components in the product.
The honest accounting is this. A six-component "system" can save real time. A 200-component system at a 12-person company is a tax. The payoff hours are linear, the maintenance hours compound, and at some point the lines cross. Most teams cross the lines without noticing because the maintenance shows up as Friday afternoon Slack messages instead of a P&L line.
AI generation just collapsed the math
The whole case for a design system rested on a single number, the cost of producing a new well-styled component. That number is now a rounding error.
A junior engineer can type "give me a settings page with a sidebar, three sections, and a save bar that follows the loading state pattern" and ship a working component in twenty minutes. v0 generates Shadcn-shaped output by default. Cursor and Claude can refactor a whole flow against existing primitives. The payoff that a design system used to provide, fast generation of consistent-looking UI, is now a free service shipped by every IDE on the market.
The system tax did not change. The payoff cratered. That is the whole story. Teams that built design systems in 2022 to get faster output are now slower than teams that ship Shadcn plus Tailwind plus a prompt because every AI tool was trained on the latter and ignores the former.
The 5% who actually need a design system
A real design system pays for itself only when a specific set of conditions are all true. Miss one and the math falls apart.
- Multiple products sharing one identity. Atlassian has Jira, Confluence, Trello, and a dozen more. One identity, many surfaces. The system is the unification layer.
- Headcount in the hundreds, not the dozens. Below 50 product engineers, every component is a Slack message away from a fix. Above 200, that does not scale and a system becomes the only path.
- A staffed design ops or design infra team. A design system without an owner is a graveyard. The owner has to be a real role, not a 20% time project.
- External consumers. Open-source design systems like GitHub Primer or Shopify Polaris are also developer-facing products. The maintenance cost is justified by external adoption.
- A regulated or accessibility-heavy domain. Healthcare, finance, government. The system encodes compliance and audit-readiness, which is a payoff no individual team can replicate.
If a team checks all five, a design system is the right call. If a team checks one or two and is shipping one product with 40 engineers, a design system is cosplay. The piece on the anti-dashboard covers a related pattern, building infrastructure for an org size you do not have yet.
The minimum viable visual system
For the 95%, the answer is a three-layer stack that costs almost nothing to maintain and produces almost the same output.
| Layer | What it is | Tools | Maintenance cost |
|---|---|---|---|
| Tokens | Color, type, spacing, radius, shadow as variables | Tailwind config, CSS variables, Figma variables | Low. One file. Updated quarterly. |
| Primitives | Headless or styled components, accessible by default | Shadcn, Radix, Headless UI, Cal.com primitives | Low. Vendored, not maintained. Update on demand. |
| Taste | A person who knows when to break the rules | A senior designer or design-literate engineer | Free if you hire well, infinite if you do not. |
That is the entire stack. Tokens give you consistency. Primitives give you accessibility and behavior. Taste gives you the layer no system can encode, which is judgment about when the rules should bend.
The teams shipping the cleanest products in 2026 use a version of this. Linear runs on a tiny token set, custom primitives, and obsessive taste. Vercel ships a heavy Tailwind config plus their own primitives.
Cal.com publishes its primitives publicly. Resend and Loops ship Shadcn-shaped UI with house tokens on top.
Notion runs on a small set of tokens and a deliberately tight component vocabulary. None of them have a "design system" in the Atlassian sense. All of them have a marketing site stack that looks more coherent than companies ten times their size.
Why Shadcn is eating the design system category
Shadcn is not a component library. It is a delivery mechanism for the new default. The primitives are vendored into the codebase, styled with Tailwind, and accessible because Radix is doing the heavy lifting underneath. The user owns the components, can edit them freely, and is never blocked by upstream releases.
That is the death blow to most internal design systems. The reason teams used to build their own was control. Shadcn gives the control for free. The reason teams used to ship Storybooks was discoverability.
Shadcn ships its docs publicly and AI tools index them. The reason teams used to publish Figma libraries was consistency. Shadcn primitives are consistent enough that any prompt against them produces output the team already knows how to evaluate.
Shadcn plus Tailwind plus a token set is the default visual stack of 2026. It is what every modern AI codegen tool produces by default. It is what every new product team ships first. It is the primitives plus taste model in two repos and a config file. The design system as a separate artifact, with its own publishing pipeline and its own team, is now the special case.
When a real system finally pays for itself
The honest version of the question "do we need a design system?" is "have we crossed the maintenance threshold yet?"
| Signal | Need a system? |
|---|---|
| Two engineers ship inconsistent buttons in the same week | No. Add a token file. |
| Three products share a brand and diverge visually | Maybe. Start with shared tokens. |
| Multiple teams ship the same component differently every quarter | Yes. Time for shared primitives. |
| A specific component is rebuilt by four teams in six months | Yes. Promote it to the system. |
| Onboarding a new designer takes two weeks because conventions are tribal | Yes. The system is now a payoff. |
| External developers consume your components | Yes. The system is a product. |
| Compliance or accessibility audits hit your roadmap | Yes. Encode it once. |
If a team hits three or more of those signals, a real system is justified. If they hit one, a token file is enough. The same logic shows up in the way the pricing page problem and onboarding without onboarding solve coordination at the surface level instead of the system level.
The pattern, then the punchline
The maturity flex is upside down. The teams shipping the most coherent products in 2026 are not the ones with the biggest design systems. They are the ones with the smallest visual debt. Tight token set, thin primitives layer, and a designer with taste who says no often.
Real design systems are infrastructure for orgs that have outgrown the alternative. They are not a milestone every team should hit. They are not a status symbol. They are not the answer to "we want to look more professional."
A team that builds one before earning the maintenance budget ships the same product on a slower clock with a heavier file. The one that ships tokens plus Shadcn plus taste ships the same product on a faster clock and uses the saved time to fix the settings page problem instead.
The question is not "do we have a design system?" It is "are we paying maintenance on the right level of abstraction?"
FAQ
What is the difference between a design system and a component library?
A component library is a set of reusable UI parts. A design system is a component library plus tokens, plus documentation, plus governance, plus an owner, plus a release cadence. Most teams ship a component library and call it a system. The two are not the same, and the second has a maintenance cost the first does not.
Is Shadcn a design system?
No. Shadcn is a primitives delivery mechanism. Components are vendored into the codebase and owned by the team. There is no central library, no upstream release schedule, and no governance.
That is the point. It gives the team the payoff of a system without the maintenance bill.
When should a startup invest in a design system?
When at least three of these are true: multiple products sharing identity, fifty plus engineers shipping UI, a staffed design ops role, external consumers of the components, or a regulated domain. Below that bar, ship tokens plus primitives plus taste and put the saved hours into the actual product.
CTA
Want a product where the visual system matches the team size? Brainy ships tokens-plus-primitives stacks for the 95% and full design systems for the 5%, calibrated to the actual maintenance budget. Hire Brainy. We will tell you which side of the line you are on before you spend a quarter on the wrong artifact.
Want a product where the visual system matches the team size? Brainy ships tokens-plus-primitives stacks for the 95% and full design systems for the 5%, calibrated to the actual maintenance budget.
Get Started
