For a long time I thought good developers avoid copying code. Install a package, import it, move on. Copy-paste was the thing you did when you were in a hurry and felt a bit guilty about it.
Then I started building with shadcn/ui, and that rule fell apart.
The odd idea at the center
The idea is simple. You do not install a component library. You add a component, and the source file lands in your own project. A button is a file in your repo. A dialog is a file in your repo. You can open it, read it, and change it.
At first this felt wrong. Where is the dependency? Where are the updates? Who maintains this?
The answer is: you do. And that turns out to be the point.
Why it fits indie work
When you build alone, you are the design team, the frontend team and the support team. Every hour matters. A normal component library is great until the day you want something it did not plan for. Then you are reading docs, searching issues, and writing awkward overrides on top of code you cannot touch.
With owned code, that day is boring. You open the file and change the thing. No workaround. No fight.
I do not need a perfect system. I need a system that gets out of my way when the product needs something odd. And a small product always needs something odd.
Owning code means owning the mess
It is not free. If a component has a bug, that bug is now in my repo. If I want a new version, I have to decide what to merge and what to keep. Nobody does that for me.
But I have found that I prefer this kind of cost. It is visible. It sits in my own files, where I can see it. A hidden dependency problem shows up at the worst time, usually right before a release. A visible one I can handle on a quiet afternoon.
It works well with AI tools too
This part surprised me. When the components are plain files in the project, an AI coding assistant can read them. It sees the real code, not a description from the docs. It can follow the patterns already there and write new pieces that look like the old ones.
When the code lives inside a package, the assistant has to guess. When it lives in my repo, it can look. Good context beats clever prompting almost every time.
The same rule, everywhere
I think this goes beyond UI. The things I trust most in a project are the things I understand well enough to change at midnight. A small script I wrote. A deploy setup I can explain in two sentences. A component I have actually read.
The things I trust least are the ones that work like magic until the day they do not.
So my rule now is quite plain. Use tools that let me own the parts that matter, and rent the parts that do not. I do not need to own my database engine. I do want to own my booking button.
Anyway. That is how I think about it these days. Copy the file, read the file, make it yours.
