Skip to content

Design

Material UI vs shadcn vs building your own

By
Staff
Published
December 18, 2025
Read
3 min read
Filed under
Design
Share

Every option sends a bill.

The question clients actually ask isn't which component library should we use. It's why does our site look like everyone else's, and why is it so expensive to fix. Those are the same complaint, and the answer lives in a decision somebody made early. The mistake isn't picking the wrong one. It's picking without knowing which bill you agreed to pay.

Google's Material as React components. Day one it's a gift: a date picker, a data grid, forty things that'd each take a week. For an internal tool we'd reach for it without blinking. The trouble starts the moment you want it to not look like Google — MUI bills in design control.

shadcn bills in maintenance. Run a command and it copies the actual component source into your project. The code is yours, change any file you like. But upstream fixes don't flow to you. You merge them by hand, across every component, across every project.

Build your own bills up front: your own layer on the unstyled, accessibility-handled primitives shadcn itself uses. You own the design completely while someone else owns the hard correctness work underneath. It costs in time now and pays back in a site that's cheap to evolve.

Stop using the tool normally.

MUI's own docs say it out loud: for heavy customization, stop theming and build new components. The official guidance for making it look like you is to stop using it the normal way.

That's not a bad afternoon. That's the whole month, hunting for which internal slot a shadow gets applied to, styles showing up in the rendered CSS while nothing visibly changes.

How much does it matter that this looks like you? That's the whole call. And its twin: how long do you intend to live in it. Those two answers pick the foundation, not the framework's popularity.

A microsite shipping in three weeks should not be hand-built. Reach for the gift. The bill it sends never comes due, because you're gone before it does. A flagship your team edits for five years is the exact case where paying up front is cheaper. The deviation tax on the wrong foundation will dwarf the build cost by year two.

The library decides how much your site is allowed to look like you.

Building your own isn't reckless when it's framed right. On a foundation someone else keeps correct, you own the look and inherit none of the hard parts. The component library is the single decision that decides how much your site is allowed to look like itself. Pick it like it matters.

Most teams never sit down and ask which bill they're agreeing to pay. That question is the whole first conversation in how we build, before a single component gets chosen.

Pick it like it matters, because it's the one decision that quietly outlives the project. It's the same standard behind the studio itself: own the foundation you're actually going to live in.