The comment thread nobody asks for until they need it

The moment we stopped ignoring comments

Before Shpd, I worked on feedback tools as features, not problems. You'd tick a box in the admin panel. "Comments: enabled." Done. But that founder at 11pm taught us something obvious in hindsight: comment threads are where voting becomes real conversation. They're where context lives. A voter says "I need this because my workflow breaks here." Another says "We built this differently last year." Your product team reads it. Suddenly the feature request isn't abstract anymore.

The problem was architectural. Most feedback tools bolt comments onto a web page. Fine if your users are sitting at a desktop, checking a link. But we build for mobile studios. Your users are in your app. They voted on an iOS or Android device. Why would they leave to comment somewhere else? They wouldn't. So the conversations never happened.

Native comments, not web detours

We rebuilt comments inside the native SDKs. iOS, Android, both from day one. A voter sees a feature request in your app. They tap to see what others have said. They add their own comment. Push notification fires. The conversation stays in context, where the feature lives, where your team watches it happen in real time.

This sounds small. It isn't. We watched studios go from zero comments per feature to three, four, sometimes eight per request. The difference wasn't that comments suddenly existed. It was that comments existed where users already were. No friction. No separate login. No "visit our roadmap website" email that half your users ignore.

What happens when your voters actually talk

A studio building scheduling apps across three different verticals noticed something in month two. Voters in their restaurant app were arguing with voters in their medical practice app about the same feature. Different use cases, same problem. The comments revealed it. The team built the feature once, smarter, because they'd read the thread.

Another founder told us her most active voter was a power user she'd never heard of. Lurking in comments. Adding context. Making the case for priorities. She'd have missed that person entirely without a comment thread. Now they're part of her product council.

Comments also surface the obvious rejections early. Someone asks for feature X. A comment says "we tried this three years ago, killed it, here's why." Your team doesn't build the same dead end twice. The comment thread becomes institutional memory that voters can see.

Building something that doesn't scream for attention

We kept comments simple. No threading replies to replies. No upvotes on comments. No nested hierarchies that turn a feature request into a Reddit thread. Just a chronological list of what people thought, timestamped and clear. You read it. You understand the context. You move on.

Some feature platforms make comments the main event. Ours stay in the background unless someone needs them. A voter doesn't open your app to read comments. They open it to vote. The comments are there if the conversation matters. That balance took longer to get right than we expected.

The real reason we kept rebuilding it

Every time we've shipped an update to comments, it's been because a studio showed us a moment where the thread mattered. An edge case. A workflow. A missed notification. A formatting request. We don't have a product roadmap somewhere declaring "comments are done." We have studios running real apps, with real voters, surfacing real needs. That 11pm message wasn't a support ticket. It was a design brief.

A few studios came to us from other platforms last year, mostly because those platforms changed their pricing in ways that didn't work for their economics. But staying here, building with us, comes down to something narrower. They need their feedback to live where their users live. Comments included. Not as a feature. As part of how voting actually happens.