Field note · 2026

Which design system
to build on in 2026.

The most-asked question in r/UXDesign and r/Frontend, treated like a real question instead of a debate. Five scenarios, five concrete recommendations, the anti-patterns to avoid, and the 2025–26 shifts that changed the answer. No hot takes — just a decision.

On this pageThe TL;DR Five scenarios What changed since 2023 What I'd actually do

01 — The TL;DR

Five team shapes. Five answers.

There is no single "best" design system because there is no single team shape. The mistake people make on Reddit is asking "is Material/Polaris/shadcn the best?" when the question is "what should a team like mine build on?". Different question; different answer.

What follows is the answer this site would give a friend over coffee. Opinionated, explained, and bounded by team shape — not by which framework has the most GitHub stars.

Team shape

Pick

Avoid

Solo / pre-PMF startup

shadcn/ui + Tailwind

MUI, building from scratch

Mid-size SaaS (10–100 eng)

shadcn + own token layer + Polaris-shaped patterns

Adopting Polaris/Carbon wholesale

Enterprise portfolio (100+ eng, multi-platform)

Custom system, Carbon-shaped architecture

shadcn as foundation, Material lock-in

Multi-brand platform

Atomic tokens + headless components (Radix/Aria) + per-brand themes

MUI/Chakra/Carbon as base, per-brand forks

Marketing-only

Brand kit, no component library

Forcing a product-system shape on creative work

02 — Five scenarios

The actual answer, for the actual team you're on.

Find the scenario that matches yours. Each one names the recommendation, the reasoning, the dependencies you should reach for, and — equally important — the popular choices you should specifically not make.

Solo designer or two-engineer startup

Pre-PMF · one product surface · 1–5 people

shadcn/ui

shadcn/ui + Tailwind. Don't build a system. Build product.

Why this

Pre-PMF UI keeps changing. A system you maintain is pure overhead.
shadcn ships components into your repo as plain React files. You modify them in place — no upgrade pain, no version negotiation.
Tailwind handles the design tokens implicitly. You don't need a token catalog when you have ten components and one designer.

Specifically avoid

Material UI / MUI: locks you into Google's design decisions; expensive to escape later.
Chakra / Mantine / Ant Design: better than MUI but still framework-shaped. You'll fight them when your product diverges.
Building your own components from scratch: weeks of work to reach where shadcn starts.

Mid-size SaaS

Post-PMF · 10–100 engineers · 3–15 designers · 1–3 surfaces

shadcn + own tokens

shadcn baseline + your own token layer + the 10–15 patterns specific to your product.

Why this

You need consistency across teams but flexibility to evolve. shadcn gives you a copy-pastable starting point; you own the tokens.
Borrow architecture from Polaris: three-layer tokens (primitive → semantic → component), opinionated patterns documented as the canonical answer.
The patterns specific to your product (your dashboard, your wizard, your settings shape) are where the differentiation lives. Build those, not buttons.

Specifically avoid

Adopting Polaris or Carbon wholesale: you're not Shopify or IBM. The constraints don't match.
Building everything from scratch: a year of work to reach where shadcn starts.
Skipping the token layer: shadcn's defaults will leak into every component. You'll regret it at month 18.

How Shopify's Polaris structures tokens

Enterprise with a portfolio

100+ engineers · multi-product · multi-platform (web + iOS + Android)

Custom · Carbon-shaped

Build a serious custom system. Borrow architecture from Carbon (IBM) or Polaris (Shopify) — both open-source — but own it long-term.

Why this

At this scale, every external dependency is a liability. Component bugs in your supply chain become P0 incidents.
You have the staff to own it: a 5–15-person design-systems team is normal at this size.
You need governance, deprecation discipline, and cross-platform parity. Off-the-shelf systems don't ship those.
Brand differentiation matters more than time-to-market. The system itself becomes a competitive asset.

Specifically avoid

shadcn as the foundation: it isn't built for enterprise governance — version pinning, deprecation timelines, RFC process — out of the box.
Material 3: locks you to Google's design language and update cadence. Migration risk on every Material release.
Half-built: if you can't staff it like a product, don't start. A graveyard of unfinished components is worse than no system.

How IBM's Carbon ships across web, iOS, Android

Multi-brand platform

Holding company · white-label SaaS · 2+ brands sharing components

Atomic · multi-brand

Atomic token architecture + per-brand themes. Headless component layer. Reference: Atlassian, Spectrum, Salesforce Lightning.

Why this

One component implementation must support many visual brands. The split happens at the semantic-token layer, not the component layer.
Primitive → semantic → component tokens, with per-brand overrides at the semantic layer. Components stay brand-agnostic.
Headless component libraries (Radix, React Aria, Ariakit) give you behavior without baked-in design — exactly what multi-brand needs.

Specifically avoid

Anything that bakes brand decisions into components: MUI, Chakra, Carbon. They'll all need to be wrapped or forked per brand.
Per-brand component forks: maintenance nightmare. Token-level themes are the only sustainable answer.
Skipping the semantic layer: without it, every brand's colors leak into hard-coded primitive references.

How Atlassian themes one system across products

Marketing-only product

Landing pages · campaign sites · bespoke creative

Brand kit only

A brand kit, not a design system. Tokens for color, type, spacing. No component library.

Why this

Marketing wants bespoke. A component library that constrains the creative work kills what the surface exists to do.
What you actually need: brand color palette, typographic scale, a logo system, an icon set. That's a brand kit. Ship it as Figma + a CSS file.
If you're using a CMS (Sanity, Contentful, Webflow), let it own the layout primitives. Don't impose a parallel system.

Specifically avoid

Treating the marketing surface like a product app: different jobs, different constraints, different success metrics.
Building Storybook for marketing components: bureaucracy that the marketing team will route around within six months.

03 — What changed since 2023

Six shifts that changed the answer.

The recommendations above don't match the advice you'd have heard in 2022. Here's why. Six concrete things shifted between 2023 and 2026 that move the equilibrium decisively toward shadcn-shaped systems, W3C tokens, and code-first workflows.

shadcn/ui became the default code starting point

By late 2024, shadcn/ui passed every component library by GitHub stars and developer survey mindshare. The shipped-into-your-repo model — no version lock, modify in place — solved the dependency problem MUI and Chakra created. For new builds in 2026, shadcn is the question: "why not shadcn?", not "why shadcn?".

W3C Design Tokens Format became the lingua franca

The W3C Design Tokens Community Group spec stabilized in 2024. Tokens Studio, Style Dictionary, Figma, and most modern token tools now read and write it. Your tokens should be exportable to .tokens.json — it's the JPEG of design systems now.

AI coding tools made code-first systems faster

Cursor, Claude Code, v0, and the MCP ecosystem turned components written as code into the most LLM-friendly substrate. Figma-first workflows still ship, but the velocity advantage is shifting decisively toward systems where the source of truth is in the repo. This is the single biggest tailwind for shadcn-shaped systems.

Figma Variables matured but code-sync stayed paywalled

Figma Variables (2023–24) closed the gap with Tokens Studio for primitive and semantic tokens. But the Variables REST API for code-sync is gated behind Figma Enterprise. Most teams stayed on Tokens Studio + GitHub for sync. Worth knowing before you commit to a Variables-only workflow.

Design systems as products — the org pattern won

By 2025 it's not controversial: design-system teams are products with owners, roadmaps, customers (other teams), and KPIs. The "side-project that 20% of one designer's time covers" pattern is dead. If you can't staff it as a product, don't build it.

Tailwind v4 unlocked the OKLCH / P3 era

Tailwind v4's native CSS variables and OKLCH-by-default support made wide-gamut color accessible without custom infrastructure. APCA contrast is becoming the recommended baseline over WCAG 2.x ratios. The color-system bar is rising fast.

04 — What I'd actually do

The opinionated answer.

If you put me in a room with a director who has to decide this week, here's what I'd tell them. Almost every team I've seen ship a new design system in 2025 used the same recipe — and the teams that struggled almost always violated one of these.

Start in the repo, not in Figma.
Spin up shadcn/ui or the project's equivalent. Get five real components rendering in a real app. Then open Figma to back-fill the spec. Figma-first systems in 2026 take twice as long for the same outcome.
Own your tokens. Don't rent them.
Whatever component library you adopt, build a token layer that you own above it. Export to W3C .tokens.json. If you ever migrate component libraries, the tokens come with you.
Buy components. Build patterns.
A Button doesn't differentiate you. Your wizard, your settings page, your specific empty-state vocabulary do. Spend your design-system budget on documenting the ten patterns that are specific to your product, not on re-implementing what shadcn already does.
Staff it like a product.
An owner, a roadmap, a deprecation policy, a customer (your other product teams). If you can't do this on day one, postpone the system until you can.
Make it AI-readable from day one.
Your tokens, your components, your patterns should all be in formats that Cursor, Claude Code, and v0 can actually consume. W3C tokens, plain TSX components, MDX docs. The teams that get this right in 2026 ship 2–3× faster than the ones that don't.

Pick a scenario above. Then read how someone already did it.

The recommendations point at real systems. The gallery has 50+ breakdowns of how the teams behind Polaris, Carbon, Material, Atlassian, Spectrum, and shadcn actually do it — governance models, token architectures, the failed first attempts they don't put in the marketing.

Pick your tooling stack Browse the gallery Read the build playbook Compare side-by-side

Pick a scenario above. Then read how someone already did it.

Which design system to build on in 2026.

Five team shapes. Five answers.

The actual answer, for the actual team you're on.

Solo designer or two-engineer startup

Mid-size SaaS

Enterprise with a portfolio

Multi-brand platform

Marketing-only product

Six shifts that changed the answer.

shadcn/ui became the default code starting point

W3C Design Tokens Format became the lingua franca

AI coding tools made code-first systems faster

Figma Variables matured but code-sync stayed paywalled

Design systems as products — the org pattern won

Tailwind v4 unlocked the OKLCH / P3 era

The opinionated answer.

Pick a scenario above. Then read how someone already did it.

Which design system to build on in 2026.

Five team shapes. Five answers.

The actual answer, for the actual team you're on.

Solo designer or two-engineer startup

Mid-size SaaS

Enterprise with a portfolio

Multi-brand platform

Marketing-only product

Six shifts that changed the answer.

shadcn/ui became the default code starting point

W3C Design Tokens Format became the lingua franca

AI coding tools made code-first systems faster

Figma Variables matured but code-sync stayed paywalled

Design systems as products — the org pattern won

Tailwind v4 unlocked the OKLCH / P3 era

The opinionated answer.

Pick a scenario above. Then read how someone already did it.

Which design system
to build on in 2026.

Which design system
to build on in 2026.