The Idea That Wouldn't Go Away

Every side project starts the same way: with a problem you've noticed, a gap you want to fill, or an idea that keeps coming back to you in the shower. For me, it was a simple tool I kept wishing existed — something I found myself building workarounds for in spreadsheets, text files, and half-finished scripts.

Eventually, I decided to stop wishing and start building. What followed was one of the most educational experiences of my professional life — and not always in the ways I expected.

What I Got Right

Starting Small on Purpose

The best decision I made early on was deliberately constraining the scope. Instead of building the full vision, I defined a "version zero" that did exactly one thing well. This kept me moving when perfectionism would have stalled me, and it meant I was getting real feedback early rather than theorizing in isolation.

Shipping Before I Was Ready

There's a famous principle in product development: if you're not embarrassed by your first release, you shipped too late. I was definitely embarrassed — and that embarrassment turned out to be incredibly productive. Early users told me immediately what mattered to them and what didn't. Several of my assumptions were wrong. Better to find that out in week three than week thirty.

What I'd Do Differently

Talk to Users Earlier

I spent too long building in private. I told myself I'd share it "when it was ready" — but "ready" kept moving. The right approach is to start talking to potential users before you write a single line of code. Understand the problem they actually have, not the problem you assume they have. The gap between those two things is where most side projects quietly die.

Be More Ruthless About Scope

Even with my deliberate effort to stay focused, feature creep crept in. A small "nice to have" here, a "this will only take an hour" there — and suddenly the project is twice as complex as the original plan. Every addition has a carrying cost: maintenance, documentation, edge cases, cognitive load. Say no more than you think you need to.

Treat It Like a Real Project From Day One

I initially treated the project like a hobby — working on it when I felt like it, with no particular deadlines or structure. This led to long gaps of inactivity and momentum loss. The projects that survive are the ones you treat with professional discipline: regular time blocks, clear milestones, and accountability (even if just to yourself).

What Side Projects Actually Teach You

Beyond the technical and product skills, building something from scratch teaches you things that are hard to learn any other way:

  • How to make decisions with incomplete information — because you always have incomplete information.
  • How to maintain motivation without external accountability — the hardest part of any independent project.
  • How the whole product fits together — from infrastructure to user experience to the words on every button.
  • How to handle the emotional cycles of building — the highs when things click, the lows when nothing works.

Was It Worth It?

Unambiguously, yes. Not because the project became something huge — it didn't. But because the process made me a better developer, a better thinker, and a more empathetic collaborator. When you've felt the frustration of a confusing user flow from the builder's side, you approach every product decision differently.

If you have an idea that won't leave you alone, that's probably a sign. Start small. Ship early. Learn constantly. The project itself is almost beside the point.