Nobody asked me to build a menu bar token counter. Nobody requested a feed blocker that targets individual feeds instead of entire apps. Nobody was out there begging for a photo-based nutrition tracker.
I built all three anyway. And they turned into real products that real people use.
Here's why I think every developer should do the same.
The Best Products Come From Annoyance
Every tool I've shipped started the same way: I got annoyed by something, looked for a solution, found nothing good enough, and built my own.
With TokenBar, it was the frustration of not knowing how much my AI coding sessions were costing me until the bill hit. I wanted a number in my menu bar — always visible, always updating. That's it. No dashboard to open, no browser tab to check.
The existing solutions were either too complex (full observability platforms) or too simple (manually checking your provider's billing page once a month). The middle ground didn't exist, so I made it.
Scratching Your Own Itch Is a Superpower
When you build for yourself, you skip the hardest part of product development: figuring out what to build. You already know the problem intimately. You know the edge cases because you live them.
I don't need user interviews to understand why a developer wants to see token counts in real time. I am that user. Every design decision flows from direct experience, not guesswork.
This has a compounding effect. You ship faster because you're not debating features — you know which ones matter. You test more thoroughly because you actually use the thing daily. And your product roadmap writes itself because every frustration you hit becomes the next feature.
"But Will Anyone Else Want It?"
This is the question that kills most side projects before they start. Developers convince themselves they need to validate the market before writing a single line of code.
Here's what I've learned: if you have a problem, other people have it too. You are not that unique. The developer who's annoyed by the same thing you're annoyed by is out there — they just haven't bothered to build a solution either.
The key is specificity. Don't build a "productivity platform." Build the exact tool you wish existed. The narrower the problem, the more passionately the right users will adopt it.
The Uncomfortable Truth About Side Projects
Most developer side projects fail because they're built for an imaginary user. The developer thinks "wouldn't it be cool if..." instead of "I need this right now."
Cool ideas are cheap. Daily frustrations are valuable.
My rule: if I wouldn't use it myself every single day, I don't build it. That filter alone has saved me from dozens of dead-end projects and led me to three that actually ship and serve users.
Start With Your Own Pain
Next time you're frustrated by a tool, a workflow, or a missing feature — don't just complain about it. Build the thing. Make it exactly how you want it. Polish it until it fits your workflow perfectly.
Then put it out there. You'll be surprised how many people were waiting for exactly what you built.
The world doesn't need another todo app. It needs the weird, specific, opinionated tool that only you would think to build — because only you have that exact combination of frustrations and skills.
Go build something nobody asked for. That's where the best software comes from.
I'm a solo dev shipping native Mac and iOS apps. Currently building TokenBar (menu bar token counter), Monk Mode (feed blocker), and MetricSync (photo nutrition tracker). All three started as tools I built for myself.
Top comments (0)