Why we're not rushing polls and word clouds

What they're asking for

Polls and word clouds are the obvious next features for Feedr. I get it. If you're running a live session, letting your audience vote on something feels natural. Word clouds turning comments into a visual snapshot feels even more impressive.

The requests come from real use cases, too. A lecturer wants to gauge understanding mid-lecture. A speaker wants to open a voting round on the next topic. A podcast host wants to see the most common reaction to a question, visualised.

These are not bad ideas. They're genuinely useful. The problem is not whether we should build them. It's when, and at what cost.

The trap of obvious features

Here's the thing nobody tells you about running a small team. Every feature you add is not just code. It's support emails. It's edge cases. It's a new surface for bugs that nobody anticipated.

Polls sound simple until you ask: What happens if the host disconnects mid-poll? Can the audience see results before the poll closes? Can the host change the poll after it's started? Does the session report include poll data? Does that data need to be exportable?

Word clouds are even messier. How do you handle profanity? How do you weight words that appear multiple times? How do you present a visual that doesn't look broken on a phone versus a laptop? Do you include deleted comments in the cloud?

We built Feedr on a single principle: comments, upvoting, emoji reactions, and Q&A. Four things, done well. The moment you add polls and word clouds, you're no longer a focused tool. You're a feature soup.

What we're really optimising for

When someone joins a Feedr session via QR code, they don't create an account. They don't download anything. They don't wait. They're live in seconds.

That simplicity is not accidental. It's the core of what we do. Every engineer hour we spend on Feedr should make that experience better or more reliable, not wider.

Right now, we're focused on things that directly serve that promise. We're improving the moderation tools so hosts with large audiences can keep the conversation on track. We're building a better analytics dashboard so speakers can actually learn from what their audience engaged with. We're making sure the emoji reactions work flawlessly even when 500 people react simultaneously.

Polls and word clouds sit in the backlog because they require infrastructure we don't yet have, testing we haven't done, and support burden we're not ready to carry. More importantly, they distract from the core job: making real-time audience interaction dead simple.

The version of features that might exist

I'm not saying polls or word clouds will never happen. I'm saying we're not forcing them into a Feedr release because they're trendy or because people ask for them weekly.

When we do tackle them, they won't be the bloated voting systems you see in webinar platforms. They'll be minimal, focused, and purposeful. A poll might be five options, live results, done. A word cloud might be a single-tap visual of the most upvoted comments, no more.

But that version doesn't exist yet. Building it properly means understanding how it changes the host's job during a live session, how it affects audience attention, and what it actually adds that our existing comment stream and emoji system don't already do.

Until we know that, we're building backwards from the question 'Would this make Feedr better for someone running a lecture hall in real time?' Not 'Can we technically ship it?'

What we're learning from the asks

Every request is data. The pastor wanted a quick audience pulse. The conference organiser wanted to run a structured question. These are real problems, just maybe not the problems Feedr solves best.

For some people, that's fine. They'll use a dedicated polling tool alongside Feedr. For others, it signals that maybe Feedr isn't quite the right fit for their use case, and that's okay too.

What the requests have taught us is that our Free tier users are running serious events. They're not tinkering. They're leading classrooms, preaching to congregations, hosting conferences. That means our backlog should reflect their real constraints, not just feature completeness. It means we need to be honest about what Feedr does and what it doesn't.