Why Your First Project Should Be Embarrassingly Bad
My first project crashed on rotation, had a hardcoded API key, and an icon I made in PowerPoint. It was the most important thing I ever built.
#3 · 🧠 Mindset · See the full roadmap →
My first project had a hardcoded API key in the source code. The navigation crashed if you rotated your phone. The icon was something I made in PowerPoint.
I shipped it anyway. It got maybe 12 downloads, most of them from my family. I’m pretty sure my mom downloaded it twice because she thought the first one didn’t work.
That project was terrible. It was also the most important thing I ever built.
The perfectionism trap
I talk to a lot of junior developers who have been “working on” their first project for six months, a year, sometimes longer. They’re still tweaking it. Still refactoring. Still reading about the “correct” architecture before writing more code.
They’re not building. They’re hiding.
I get it. Putting something out there with your name on it is scary. What if people judge it? What if other developers look at the code and think you’re bad at this? What if it gets a one-star review — or worse, no reaction at all?
Here’s what actually happens: nobody cares. Not in a mean way. In a freeing way. Whether it’s an app on the store, a tool on GitHub, or a side project on your portfolio — your first one will be invisible. Nobody is going to find it and judge you.
What shipping teaches you that building doesn’t
There’s a set of skills you can only learn by actually releasing something. Not by reading about releasing. Not by planning to release. By doing it.
You learn how deployment works — the real version, not the documentation version. You learn that your project breaks in environments you didn’t test in. You learn that the feature you spent two weeks on doesn’t get used, and the thing you threw in last-minute is the one people mention.
You learn that real users do things you never imagined. They click things you didn’t expect. They enter text in fields you thought were obvious. They find bugs in features you were sure were solid.
None of this happens while it’s sitting in a private repo.
“But it’s not ready”
It’s not. It won’t be. That’s fine. Ship it anyway.
Your code six months from now won’t be good enough either, by the standards of you-in-two-years. This never stops. If you wait until your code is good enough, you will wait forever, because the finish line keeps moving as you improve.
The developer who shipped ten bad projects and learned from each one is in a completely different place than the developer who spent the same time perfecting one project that nobody ever used.
I still cringe when I look at my old code. That cringing is evidence that I’ve grown. If you look at code you wrote six months ago and you’re NOT embarrassed, that’s the worrying sign — it means you haven’t improved.
Just ship the thing
If you have a side project sitting in a private repo right now — half-finished, messy, not quite ready — I want you to seriously consider shipping it. This week. As-is.
It doesn’t need to be good. The act of shipping it will teach you things that six more months of building never will.
Your second project will be better. Your third will be better than that. But none of them happen until the first one is out the door.
Make it embarrassingly bad. Ship it. Move on. That’s how this works.
← Previous: Git in 20 minutes → Next: The #1 reason junior devs burn out (coming soon)
devkoan · Build it. Ship it. Earn from it. Every week: one tool, one lesson, one step forward. Hit reply if something here helped. I read every one.
I’ve shipped over 20 projects in the past decade. The first few were awful. I wrote down every mistake I made along the way — 100 of them, collected into a free guide for junior developers. Download it → devkoan.gumroad.com