I built a feature voting tool. And the first version had a stupid, obvious flaw that took me way too long to notice.
Every vote counted the same.
A person on your free plan? One vote. Your biggest customer paying $6,000/year? One vote. Same weight. Same influence on your roadmap. I shipped it like that because that's how every other voting tool works and I didn't think twice about it.
Then I started watching how actual teams used it. And the pattern was always the same.
The free plan trap
Here's what happens. You launch a voting board. Free users flood in because they have opinions and time. They upvote "dark mode" and "mobile app" and "more free storage." Your board lights up. Fifty votes on dark mode. Three votes on that Salesforce integration your enterprise customers keep mentioning in support tickets.
Dark mode wins. Obviously. 53 to 7.
So you build dark mode. Takes your team six weeks. You ship it. And then... nothing. Churn doesn't move. Revenue doesn't move. NPS stays flat. You check who actually voted for dark mode. Ninety percent are free users. They got what they wanted. They still didn't upgrade.
Meanwhile those five people who wanted Salesforce integration? They're each paying you $500/month. That's $2,500 in MRR standing behind that request. Dark mode had $150 in MRR behind it. You built the feature backed by 16x less revenue because the number next to it was bigger.
I watched this happen to three different teams using an early version of VoteFirst before it clicked for me. The vote count isn't demand. It's noise.
Counting heads is the wrong abstraction
The problem isn't that votes are useless. Votes tell you who wants something. That's valuable. The problem is treating every voter as interchangeable.
When every user gets one equal vote, you're making a statement whether you realize it or not: a free user's opinion about your product direction matters exactly as much as your largest customer's. That's a weird position to hold. But if you use any standard voting board, that's exactly how your roadmap gets built.
Free users want different things than paying customers. They want the product to stay free. They want features that make paying unnecessary. Optimizing for their requests is literally optimizing for the people least likely to ever give you money.
I'm not saying ignore free users. Some of them convert and you want to understand what would push them over. But when you let them dominate the signal by sheer volume, you end up building a product that's beloved by people who don't pay and ignored by people who do.
Weighting by revenue
The fix is embarrassingly simple. Don't count votes equally. Weight them.
I tried a bunch of approaches. The one that actually works: tie the weight to what the voter pays you. A free user's vote counts as 1. Someone on your $29 starter plan counts as 3. Your $99 pro customer counts as 5. Enterprise at $500+? That's a 20x multiplier.
Go back to the dark mode vs Salesforce example with these weights. Dark mode gets 50 free votes at 1x (50) plus 3 paid votes at 5x (15). Total: 65. Salesforce gets 2 free votes at 1x (2) plus 5 enterprise votes at 20x (100). Total: 102.
Salesforce wins. The roadmap now reflects where your revenue actually comes from.
The first time I showed this to a PM who'd been using unweighted voting for a year, she pulled up her board and just stared at it. Her top 5 features completely reshuffled. The stuff that had been sitting at #1 and #2 for months dropped to the middle. Features she'd been ignoring because they only had a handful of votes shot to the top.
"These are the things my enterprise customers keep asking about in QBRs," she said. "They just never had enough votes to surface."
That's when I knew this wasn't a nice-to-have feature. It's the whole point.
The Stripe connection changed everything
Early on, people had to manually assign tiers. It worked but nobody actually did it consistently. Half the voters would be untagged, which meant half the signal was still wrong.
So I added Stripe and Paddle integrations. Connect your billing provider and VoteFirst pulls the MRR for each voter automatically. No manual tagging. No spreadsheets. The weight stays current because it syncs from your actual billing data.
This matters more than it sounds. Manual tier assignment goes stale within weeks. People upgrade, downgrade, churn. If your voting weights are based on a snapshot from three months ago, you're back to making decisions on bad data. The integration keeps it honest.
What I actually learned building this
A few things surprised me along the way.
First, the weighted scores don't always disagree with the raw counts. When they do agree, you can be confident. When they don't, that disagreement is the most valuable signal on your entire board. It means your free users and your paying customers want different things, and you need to pick a side.
Second, some teams push back on the concept. "We don't want to ignore our community." Fair. You're not ignoring them. Their votes still count. They just count proportionally to their investment in your product. A free user's voice is still heard. It's just not amplified to drown out the people funding your roadmap.
Third, the conversation inside product teams changes. Before weighted voting, roadmap debates were about gut feelings and who yelled loudest in the planning meeting. After, there's a number tied to revenue. It doesn't make the decision for you, but it makes the tradeoff visible. "We can build feature A, which has more total votes, or feature B, which has 4x more revenue behind it." That's a real conversation. "Feature A has more votes" is not.
The uncomfortable truth
If you run a SaaS product and you're using a voting board with equal votes, your roadmap is probably being shaped by the people least likely to pay you. Not because they're wrong. Because there are more of them.
You can keep doing it that way. But every time you pick the feature with the most votes instead of the most revenue behind it, you're making a bet that popularity equals business value. In my experience, it usually doesn't.
VoteFirst weights votes by revenue by default. Connect Stripe, and it just works. That's the whole pitch. I built this because I watched teams ship the wrong features for a year and got tired of it.