How I Handle Bug Reports as a Solo Developer
There’s no support team behind My Pocket — bug reports come straight to me, and I’m also the person who fixes them. That has real trade-offs, and I think it’s worth being upfront about how the process actually works.
Every report gets read by an actual person
When you use the “Report a Bug” link on the Contact page, that email lands in my inbox, not a ticketing system with a queue number and an auto-reply. The upside is that nothing gets lost in triage or closed by someone unfamiliar with the codebase. The downside is that if I’m heads-down building a feature, replies can take a couple of days rather than a couple of hours.
How I actually prioritise
- Data loss or corruption — dropped immediately, everything else waits.
- Something that blocks a core action (can’t log an expense, can’t open the app) — same day if at all possible.
- Visual bugs and rough edges — batched and fixed together, usually within a week or two.
- “Would be nice” requests — logged, genuinely considered, but not promised a date.
What makes a report fast to fix
The single most useful thing you can include is what you were doing right before it happened, and what device/Android version you’re on. “The app crashed” takes a lot longer to track down than “it crashed when I tried to add a sub-item to a shared to-do on a Pixel running Android 14.” The more specific the report, the faster the fix — often the same day.
Why I don’t outsource this
Reading bug reports directly is one of the fastest ways to understand what’s actually broken about the product, not just what a support script says is broken. It’s slower to scale, but it means the person deciding what to fix next has actually seen the raw complaint, unfiltered — which I think produces a better app than a triage layer would.
