The Copy-Paste Component Model
You own the file, so you can restyle it into a brutalist theme without fighting a library you cannot edit.
The usual trade with a component library is that you get speed now and a ceiling later. Everything is fast until the design calls for something the library did not anticipate, and then you are overriding styles you cannot see, in a package you cannot edit.
The copy-paste model removes the ceiling. You run a command, the component's source lands in your repository, and it is yours.
Why ownership changes things
npx shadcn@latest add dialogThat writes a file into components/ui/. It is not a dependency — it is code in your project, and you edit it like anything else.
For the work I do, that is decisive. This portfolio is a brutalist theme: 3px borders, hard offset shadows, no border radius, Anton display type. Every component library I have used fights that, because their defaults assume soft shadows and rounded corners, and you spend your time overriding rather than building.
When the component is a file you own, restyling it is editing a file.
The trade you are making
You own maintenance. No automatic upgrades. If an accessibility fix lands upstream, you apply it manually or you do not get it. Worth knowing before you accept the model.
Your repository is bigger. Twenty components is twenty real files to review.
Consistency needs discipline. Nothing stops two developers editing the same component in different directions. The library's rigidity was doing some work for you, and now that work is yours.
When it fits
Projects with a distinctive design where the visual identity is part of the point. Long-lived client work where I would rather own the code than depend on a package's roadmap.
When it does not: an internal admin tool where the fastest acceptable interface wins and nobody cares whether it looks like every other admin tool. Take the library, take the defaults, spend the time on the actual problem.
The transferable idea
The valuable insight is not the specific library — it is that "dependency" and "starting point" are different relationships with someone else's code, and you can choose which one you want.
For anything where the design is the differentiator, owning the source is worth the maintenance. For anything where it is not, a dependency is doing you a favour.
Resources
- Repo: shadcn-ui/ui
- Docs: ui.shadcn.com
- Video walkthroughs: YouTube: shadcn/ui tutorial
Need this built properly?
I build secure, fast, bilingual platforms for clients across Egypt, Saudi Arabia, the UAE and Kuwait.
