Skip to content
Gradland
← Blog
🚀

7 Things I Learned Shipping Side Projects

10 March 2025·2 min readTech & CodingCareer

I've shipped probably a dozen side projects over the years. Some got users. Most didn't. All of them taught me something.

Here are the seven lessons that stuck.

1. Done is infinitely better than perfect

The most valuable thing a side project can do is exist. A half-polished app that's live teaches you more than a perfect app still sitting in a localhost:3000 tab.

Ship ugly. Polish later.

2. The real product is the README

Nobody will use your project if they can't figure out what it does in 30 seconds. I've abandoned otherwise great tools because the README assumed too much.

Write the README first. It forces you to clarify what you're actually building.

3. Constraints are a gift

My best projects had artificial constraints: "I'm only allowing myself one weekend", or "no external dependencies." Constraints kill perfectionism and force creative decisions.

4. Your first 100 users are manually acquired

There's no algorithm that will discover your project. You have to go find your early users — in Reddit threads, Discord servers, Hacker News, or just by DMing people directly.

5. Burnout comes from building for the wrong reasons

Projects I started to impress others died. Projects I started because I genuinely needed the tool survived. Build things you would use.

6. Boring technology is underrated

Every time I've reached for a flashy new framework on a side project, I've regretted it. Use what you know. The novel part of your project should be the idea, not the stack.

7. The graveyard is part of the process

Most of my projects are dead. And that's completely fine. Each one was a playground where I learned something — a new API, a deployment pattern, a UI approach. The "failure" was always just a tuition fee.


What has shipping taught you? I'd love to know.

🤖

Feed this to Buddy?

Worth 2 XP · 🌿 leafy green · feeds & evolves your TamaAussie

← All postsThanks for reading 🌿