By Mehdi HassanShould a startup use shadcn/ui or build a custom design system?
A startup should use shadcn/ui first and turn it into a custom design system later, once the team is big enough that inconsistency costs real time. The two options aren't opposites. shadcn/ui gives you the code for accessible components, and a custom system is what you get after you've given them your own tokens, type, rules and product-specific pieces.
The question founders are really asking is whether to spend design and engineering time on components now or on the product. Early on, the product wins. Our guide to design systems for startups covers the broader timeline. This article is about one decision inside it: what to build your UI on, and how to move from a stock look to a branded one without a rewrite.
What is shadcn/ui, and how is it different from a component library?
shadcn/ui is a collection of React components you copy into your own codebase with a CLI, rather than install as a package. The components are built on accessible headless primitives (Radix UI originally) and styled with Tailwind CSS, with colors and radius driven by CSS variables. Because the code lives in your repo, there's no version to upgrade and nothing you can't change.
That's different from a classic component library such as MUI, which you install as a dependency and customize through a theme object and overrides. A library gives you more components out of the box and a consistent default look. The cost is that heavy restyling fights the library, and upgrades can change behavior you depended on.
shadcn/ui | Packaged library (e.g. MUI) | Custom design system | |
|---|---|---|---|
Where the code lives | Your repo | node_modules | Your repo or an internal package |
Default look | Neutral, easy to restyle | Strong, opinionated | Yours |
Accessibility | Inherited from headless primitives | Built in | Only as good as you build it |
Theming | CSS variables and Tailwind | Theme object and overrides | Your tokens, any method |
Upfront cost | Low | Low | High |
Upkeep | You maintain copied code | Upgrades and breaking changes | A person or team, ongoing |
Brand distinctiveness | Low until you restyle | Low to medium | High |
When does a custom design system make sense?
A custom design system makes sense when the cost of inconsistency is bigger than the cost of maintaining a system. The thresholds people commonly cite are two or more designers or three or more engineers shipping UI. Below that, one person can hold the conventions in their head. Above it, you start seeing three button styles and four grays.
Team size isn't the only trigger. These situations also justify investing earlier:
- Your brand is the product's edge. Consumer apps and design-led B2B tools where looking like every other SaaS hurts sales.
- You run more than one product or surface. A web app, a marketing site and an embeddable widget need one source of truth.
- You sell to enterprises that audit accessibility. You want documented, tested components, not copied code nobody owns.
- You white-label. Multiple client themes need a deliberate token architecture from the start.
What are the trade-offs of starting with shadcn/ui?
Starting with shadcn/ui trades distinctiveness for speed. You ship accessible, decent-looking UI quickly, and the price is that untouched shadcn apps look alike. That's fine for an internal tool or an MVP and a problem for a brand that needs to stand out.
Pros
- Accessible keyboard and focus behavior from the headless primitives
- You own the code, so no library upgrade can break your UI
- Theming through CSS variables maps directly to Figma variables
- Huge community, so most patterns already have an example
- Pairs naturally with Tailwind and Next.js, which most startups already use
Cons
- The default look is everywhere, and users notice
- Copied code means you own the bugs and fixes too
- No built-in documentation or usage rules for your team
- Fewer complex components (data grids, date ranges) than big libraries
- Teams often fork components ad hoc, creating drift
The last con is the one that bites. Because editing a shadcn component is so easy, different engineers tweak the same component in different places. The fix isn't to avoid shadcn. It's to treat the copied components as your system from day one: one folder, one owner, changes reviewed.
How do you migrate from shadcn/ui to a branded design system?
You migrate from shadcn/ui to a branded system in place, in five stages, without stopping product work. Each stage is shippable on its own, and the order matters because later stages depend on stable token names.
Rename and expand the tokens
shadcn's default variables (background, foreground, primary, muted, border) are a good start but too few. Map them to a fuller semantic set like color/bg/surface and color/text/muted, as described in our guide to design tokens. Keep the old names as aliases so nothing breaks.
Mirror the tokens in Figma
Set up matching Figma variables with the same names and light and dark modes. From here, a color change in Figma has an obvious twin in code, and you can sync Figma variables to code instead of copying hex values.
Restyle the primitives
Apply your type scale, radius, shadows and motion to the copied components. This is where an app stops looking like shadcn. Button, input, select, dialog and table do most of the visual work.
Add signature and product components
Build the components only your product has: the specific card, the status chip, the empty state, the data table with your filters. These carry your brand more than any button does.
Write the rules down
Document when to use each component and when not to. Without usage rules, even a well-built system drifts within months.
Hypothetical example: a seed-stage SaaS outgrowing stock shadcn
For example, suppose a seed-stage B2B SaaS has two engineers and a part-time designer, and built its MVP on stock shadcn/ui. After the raise, they hire a second designer and two more engineers. Within a few months there are three versions of the stat card and dark mode is broken on half the settings pages.
The practical move is not a rebuild. They'd spend a fixed design sprint defining tokens, type and the five signature components in Figma, then have engineers apply them to the existing shadcn folder over a couple of sprints, behind the same component names. Product screens barely change in code. They just start looking like one product.
How much does each option cost a startup?
shadcn/ui costs nothing to license and little to set up, so its real cost is engineering time spent maintaining the copied code. A custom system costs design time up front and ongoing ownership. A packaged library sits in between, with low setup cost and a long tail of override work if you restyle it.
For a startup, the expensive mistake is building a full custom system before product-market fit, then redesigning the product anyway. Spending a small, fixed amount on tokens and type, applied to shadcn, gets you most of the brand benefit for a fraction of the effort. Our design system cost guide breaks the tiers down, and the MVP development cost guide shows where this fits in a first-version budget.
Should you use shadcn/ui on your marketing site too?
You can, but a marketing site needs different components from an app. Hero sections, pricing tables, logo rows and long-form content blocks aren't in shadcn, and they carry most of the brand. Sharing tokens between app and site matters more than sharing components.
The approach we use is one token layer for both, and separate component sets: shadcn-based for the app, custom section components for the site. Our guide to building a design system for a Next.js marketing site explains that split.
