What Three Years of Side Projects Taught Me
I've shipped 12 side projects. Two got traction. Most died quietly. The patterns across success and failure are clearer in hindsight than they ever were in the building.
Arian ShahThree years ago I started taking side projects seriously. Not as portfolio pieces — as real products, built to solve real problems, shipped to real users.
I've launched 12. Here's what I actually learned.
The projects that died
Most died for the same reason: I built something I thought was interesting, not something people needed.
The clearest example: I spent six weeks building a keyboard shortcut manager for macOS. Polished UI. System-level permissions. Sync across devices. Launched to 200 HN readers and got 11 sign-ups, zero retention.
Didn't talk to a single potential user before writing a line of code.
The project after that: I found a repeated complaint on a subreddit about a specific workflow problem, DMed ten people asking if they'd pay for a solution, got three "yes, please hurry" responses, and built the minimum thing that solved exactly that problem. Still running today, covers my coffee budget every month.
The difference wasn't execution quality. It was whether I validated that the problem was real before I started building.
The thing about scope
Every project I've shipped in under two weeks has had a better outcome than every project that took more than a month.
This sounds like obvious advice. It's not. The reason long projects fail isn't laziness or losing interest — it's that the initial idea was too abstract, so the scope kept expanding to cover edge cases that wouldn't exist if you'd just talked to users first.
The two-week constraint is a forcing function. You can't over-engineer what you don't have time to over-engineer.
Technology is the wrong variable
I spent way too much time early on choosing the "right" stack. Agonized over whether to use SvelteKit or Next.js for a project that would have 80 users.
The stack doesn't matter. Postgres can handle more traffic than you'll ever get. The ORM you already know is better than the one you've been meaning to learn. The framework you're productive in ships faster than the one you're excited about.
I now default to the same stack for every project: Next.js, Tailwind, Postgres, Vercel. Boring and fast.
What "traction" actually looks like early
Not traffic. Not sign-ups. Not even revenue.
Traction at the early stage is: someone uses your product without you asking them to. One person who found you, signed up, came back the next day — that's signal. A hundred people who signed up because you tweeted about it and never returned — that's noise.
The metric I track in week one: do any users return on day 7 without a prompt from me? If yes, I've found something worth continuing. If no, I either pivot or kill it.
The cost of giving up too early vs. too late
These are equally bad mistakes, and I've made both.
I killed a project with 40 active weekly users because growth had stalled. Turned out I just needed to write two blog posts about the use case. The next project I held on to for six months past the point where any honest assessment would have said "this isn't working."
The test I use now: can I name three concrete things that could unlock growth? If yes, do them, then reassess. If I'm just waiting for something to change on its own, that's a dead project in slow motion.
Side projects are a compounding investment. The skills, judgment, and network you build ship faster with each one. The goal isn't any individual project — it's the version of you that exists after building twelve of them.