The simplest way to stop runaway vote stacking on a feedback board is to cap votes per post. In FeatureOS you set a maximum number of upvotes and downvotes per post on each board. Once a post hits the cap, new votes stop until someone removes theirs. One idea can no longer drown out everything else on the board.
TL;DR: Go to Dashboard > Boards > pick a board > Settings and set the upvote and downvote limits for posts on that board. The cap is per board and covers both upvotes and downvotes. It limits how far a single post can climb. It does not detect bots, fake accounts or coordinated voting, and it does not weight votes.
A feedback board is only useful if the vote counts mean something. When one request picks up a few hundred votes because someone shared it in a community channel, the board stops telling you what your customers need. It tells you who has the biggest audience.
That is the problem vote caps solve. This post covers what the cap does, how to set it up, when it helps, and where it stops helping.
What counts as vote manipulation on a feedback board?
Most of the time it is not malicious. It looks like this:
- A customer posts their request in a Slack community and asks everyone to upvote it.
- A partner rallies their own users around one integration.
- A post gets linked from a popular thread and keeps collecting votes long after the signal was clear.
- A rival idea gets a pile of downvotes from people who simply prefer something else.
None of these break any rules. They still distort the board. A request with 400 votes looks 10 times more important than one with 40, even when the 40 came from your best customers.
This is a version of vocal minority bias: a small, loud group shapes what looks like consensus.
What does capping votes per post actually do?
You set a maximum number of upvotes and a maximum number of downvotes for posts on a board. The limits apply to every post on that board.
When a post reaches the cap, it stops taking new votes. If someone removes their vote, a slot opens up and someone else can vote.
The point is to keep popular requests from runaway vote stacking, and to keep the board fair when one idea starts to dominate. Past a certain number, more votes do not tell you anything new. The cap makes that explicit.
Because limits are set per board, you can treat boards differently. A public board that anyone can find might need a cap. A private board for a handful of enterprise accounts probably does not.
How do I limit votes on feature requests in FeatureOS?
- Open your FeatureOS Dashboard.
- Go to Boards, then pick the board you want to cap.
- Open Settings for that board.
- Set the upvote limit for posts on that board.
- Set the downvote limit for posts on that board.
- Repeat for other boards that need their own limits.
Source: Cap votes per post, shipped 2026-10-05.
How do I pick the right cap?
There is no magic number. A few ways to think about it:
- Look at your current board. Sort by votes. Find the point where the top posts stop being meaningfully different from each other. A cap near that point keeps the ranking useful without hiding real demand.
- Think about the size of your audience. A board with a few hundred active users needs a lower cap than one with tens of thousands.
- Set downvotes separately. If downvotes on your board are mostly people expressing a preference, a lower downvote cap stops a single unpopular idea from getting buried.
- Revisit it. Check the board after a few weeks. If several posts sit at the cap, either the cap is too low or you have more than one clear winner. Both are worth knowing.
Example (hypothetical): one integration request takes over the board
A developer tools company runs a public Feature Requests board. A request for a specific integration gets shared in a large community forum and climbs far above everything else in two days. The PM already knows the integration is wanted. Every extra vote just pushes other requests further down the list, where nobody sees them.
The PM opens Boards > Feature Requests > Settings and sets an upvote limit. The integration post stops at the cap. Other posts get seen again. The PM still has the comment thread on the integration post to read for detail, and the ranking on the rest of the board is useful again.
Example (hypothetical): two boards, two policies
A company runs two boards. The Public Ideas board is open to anyone. The Customer Advisory board is for a small group of paying accounts.
They cap upvotes and downvotes on Public Ideas, because that board gets traffic from social links and forum threads. They leave Customer Advisory without a cap, because every vote there comes from someone they know and they want the raw count.
Same product, same team, different rules. That is why the setting lives on the board.
When is this not enough?
A vote cap is a blunt tool. It is good at one thing: stopping a single post from running away with the count. Be clear about what it does not do:
- It does not detect fraud. The cap does not look at who is voting. It does not find bots, duplicate accounts or votes from the same IP address.
- It does not weight votes. A vote from your largest customer counts the same as a vote from a first-time visitor. The cap only limits the total.
- It hides demand above the cap. Once a post is capped, the count stops growing. If you need to know whether a request has 300 or 3,000 supporters, a cap will not tell you.
- It cannot fix a skewed audience. If the people on your board are not the people you build for, capping votes does not change that.
The fix for most of these is the same: votes are an input, not a decision. Read the comments. Talk to the people who voted. Look at which customers are asking, not just how many.
How does this fit with the rest of FeatureOS?
Vote caps keep the board honest. The rest of the workflow is collecting requests, merging duplicates, prioritizing and closing the loop when you ship. Our feature request software page covers that end to end.
When a capped request gets approved, you can route it to engineering with automatic Jira push rules, or see the Jira integration page for the full setup. If you would rather triage from your terminal, see how to manage feedback via Claude Code.
Try it on your own board
FeatureOS plans are seat bundles: Starter at $60/month for 5 seats, Growth at $120 for 10, Business at $250 for 15, and $15 per extra seat. There is no free plan.
Start a 14-day free trial, open a board's settings and set your first cap. If you need more time to see how it changes your board, ask us and we can extend the trial to 30 days.