Let’s start with the heresy:
Most apps don’t need a design system.
Not a proper one. Not the Figma-to-React pipeline with tokens, themes, dark mode variants, and 500 component abstractions.
You probably don’t need that.
But you’re being told otherwise — by blog posts, bootcamps, agencies, and job listings that treat “Design System” as gospel.
If your app doesn’t have one, how will you scale? How will you maintain consistency? How will you sleep at night?
Let me offer a simpler answer: you’ll be fine.
The Cult of Consistency
Design systems promise consistency, scalability, and velocity. That’s the sales pitch.
But the pitch skips the cost column:
- Upfront complexity
- Maintenance overhead
- Creative friction
- Premature abstraction of UI before your product even finds traction
It’s the frontend version of “microservices from day one.”
Premature optimization dressed in style tokens.
When you’re building a tool, not a platform, the ROI just isn’t there.
Who Actually Needs a Design System?
Design systems make sense for:
- Multi-team orgs shipping UI across multiple products
- Highly regulated apps needing locked-down visual semantics
- Public platforms with external consumers of your components
If that’s not you, you’re likely better off with:
- A lightweight component set
- A solid Tailwind config or scoped CSS approach
- Sensible conventions and a dash of taste
No tokens.
No DSLs.
No 30-minute debates over primary button variants.
The False Economy of Scale
The design system mindset assumes everything will grow.
But most apps don’t.
And if yours does? You can refactor toward a system when the need is proven — not predicted.
Until then, every hour spent polishing component APIs is an hour not spent improving your product.
Every abstracted button is another layer between your user and their goal.
The goal is clarity, not elegance.
Ship usefulness, not architecture.
Design Systems as Vanity Architecture
Design systems thrive in portfolio projects and enterprise teams with low shipping pressure.
Why? Because they feel productive. They feel correct.
But they often optimize for internal coherence over external utility.
They make it easy to forget the user.
Because users don’t care about your design tokens.
They care that the app works.
The Counter-Pattern: Design Curation
Instead of a system, think in terms of curation.
Pick a few reusable patterns.
Prune aggressively.
Use the same button until it hurts.
Let aesthetics emerge from constraint — not config.
That’s how real products evolve:
Through intentional reuse and gradual coherence, not central planning.
You Can Always Add It Later
Here’s the kicker: nothing is stopping you from systematizing later.
- Once patterns actually need consolidation
- Once you’ve shipped enough to know what matters
- Once the pain is real, not imagined
Until then:
- Keep your components humble
- Keep your codebase boring
- And stop LARPing as Shopify