There’s no support team here. When something breaks, or someone has a request, or someone’s just annoyed enough to say so, it comes straight to me. That’s exhausting some weeks and it’s also, honestly, the best source of product direction I have. A handful of emails from actual users have shaped this app more than any roadmap session I’ve ever run solo. Here’s some of what they taught me.
The Complaint I Almost Dismissed
Someone emailed early on annoyed that swiping past a post felt “too final” — no easy way to go back if you swiped too fast and missed something. My first instinct was to dismiss it. The whole point of the app is a forward-moving scroll; going backward felt like it worked against the design. I filed it as a one-off preference and moved on.
Then two more people mentioned some version of the same thing within a couple of weeks, unprompted, in completely different words. That’s the actual signal I’ve learned to watch for — not the first complaint, which is often just one person’s specific preference, but the same complaint arriving independently from people who have no idea the others said anything. A basic “go back one” gesture shipped shortly after. It’s one of the more-used interactions in the app now, and I almost talked myself out of building it.
The Bug Report That Took Me a Week to Believe
A user reported that the app was crashing specifically when they had a certain type of home network setup — a detail so oddly specific I genuinely doubted it was real for the first few replies. I couldn’t reproduce it on anything I had access to. It would have been easy to quietly close the thread as “can’t reproduce” and move on, which is a real temptation when you’re the only person triaging your own bug reports and there’s no one checking whether you’re being thorough.
I kept the thread open instead, mostly because the user was specific and patient rather than vague and frustrated, which is usually a good sign the report is real. It took about a week of back-and-forth to isolate — a networking edge case that only showed up under a specific combination of conditions almost nobody hits, except, apparently, more people than I assumed. Fixed, eventually. The lesson wasn’t really about the bug. It was about not letting “I can’t reproduce it” become an easy excuse to stop looking.
What Being the Whole Support Team Actually Teaches You
The obvious downside of being a one-person support team is the obvious one: it doesn’t scale, and a bad week for bug reports is genuinely a bad week. The less obvious upside is that nothing gets filtered before it reaches me. There’s no support tier deciding which complaints are worth escalating. I see the actual raw signal, unsummarized, including the reports that would probably get deprioritized by a support team trying to manage volume. Some of the best product decisions I’ve made came directly from a complaint that, on paper, looked minor enough to ignore.
The Actual Habit That Makes This Work
Every email gets read the same day, even if the fix or the reply takes longer. Not because I’m especially disciplined about it — because a fast “I see this, I’m looking into it” reply is most of what makes someone willing to email again next time instead of just quietly leaving. The users who’ve emailed me more than once are, without much exception, the users who’ve shaped this app the most. That only happens if the first email actually gets a real response.
The Bottom Line
I don’t have a formal feedback process, a roadmap board, or anything close to a systematic way of collecting what users want. What I have is an inbox I actually read, and a habit of taking a complaint seriously the second or third time it shows up even if I dismissed it the first. That’s a smaller system than most products run on. It’s also, so far, been enough.
