When you're a solo dev shipping multiple products, feature requests hit different.
There's no PM to triage them. No sprint planning meeting. No "let's put that in the backlog." It's just you, your inbox, and a growing list of things people want.
I ship three apps right now — a Mac menu bar token counter, a feed blocker, and an iPhone nutrition tracker. Each one gets feature requests weekly. Here's the system I've landed on after months of getting it wrong.
The 3-Bucket Rule
Every request goes into one of three buckets:
1. "Hell yes" (ship this week)
The request solves a problem I also have. If I'm dogfooding my own product and the missing feature bugs me too, it's basically already approved. These requests align user pain with builder pain — that's the sweet spot.
2. "Good idea, not now" (note it, move on)
The request makes sense but doesn't serve the core use case. I keep a simple markdown file per product with these. If three different people ask for the same thing within a month, it graduates to bucket one.
3. "That's a different product" (say no politely)
Someone wants my feed blocker to also track screen time. Someone wants my token counter to generate reports for their manager. These are valid needs — they're just not my product's job. I say no, and sometimes point them to something that does what they want.
The Trap: Feature Creep Disguised as Listening
Early on, I said yes to everything. My token counter — TokenBar — started as a dead-simple menu bar widget. One number. Your token spend. That's it.
Then people wanted historical charts. Export to CSV. Team dashboards. Slack notifications.
Each request was reasonable in isolation. Together, they would've turned a focused tool into a bloated dashboard app. I had to learn that saying no to good ideas is the job.
How I Actually Decide
I ask myself one question: "Does this make the core loop better?"
For a token counter, the core loop is: glance at menu bar → see your spend → adjust behavior. Anything that makes that loop faster or clearer gets priority. Anything that adds a new loop gets scrutinized hard.
For my feed blocker, the core loop is: open a distracting site → get blocked → go back to work. Adding more granular blocking rules? Yes. Adding a productivity journal? No.
The Communication Part
I reply to every feature request. Even the ones I say no to. A simple "Thanks for this — I'm not adding it right now because [reason], but I've noted it" goes a long way. Solo devs live and die by word of mouth. Every user interaction is marketing.
What I've Learned
The best solo dev products aren't the ones with the most features. They're the ones where every feature earns its place. Your users will respect you more for a focused tool that does one thing perfectly than a Swiss Army knife that does everything poorly.
Say no more than you say yes. Your future self will thank you.
I'm building TokenBar (real-time LLM token tracking for your Mac menu bar) and a couple other tools. If you're a solo dev figuring this stuff out too, I'd love to hear how you handle feature requests.
Top comments (0)