Demand threshold auto PR
Pick a number, say ten. When a feedback cluster reaches ten unique requesters, feedback submitters and board voters combined, Usero drafts an AI pull request against your connected repo. You review the diff. Nothing merges on its own.
Every feedback tool can tell you a request hit 50 votes. Then a human has to notice, triage it, file a ticket, and hope it survives sprint planning.
Vote counts were supposed to automate prioritization, and they only did half the job: the counting is automatic, the acting is manual. The gap between "50 people asked for this" and "someone opened an editor" is where popular requests go to age. The feedback tools know it too. Featurebase's own team filed a request for upvote-threshold forwarding to issue trackers on their public board about three years ago; it has around 200 votes and remains unshipped. And even as designed, that automation would end in a filed issue, one more backlog item a human still has to pick up. A threshold that fires into a ticket queue moves the bottleneck without removing it.
How it works
Disclosure: I build Usero, so weigh that. Usero already groups feedback from every source, widget, email, Slack, GitHub issues, board posts, into clusters, and it measures demand per cluster as unique people: one person submitting five times counts once, and someone who upvoted the board post counts alongside the submitters. The threshold lives in Settings next to the other PR controls, a toggle plus a number from 2 to 10,000, off by default. A sweep checks every cluster against your number, and when one crosses it, Usero reads your repo and opens a draft pull request scoped to the open reports in that cluster. Each cluster triggers at most once, and both the cluster list and the cluster page carry an "Auto-drafted" badge so the PR's origin is never a mystery.
A vote total mixes one obsessed user with fifty quiet ones. Usero dedupes by person across every source before comparing against your threshold, so ten unique requesters means ten different humans asked, whether they typed it into the widget, replied to an email, or upvoted the board post.
Forwarding a popular request to Linear or Jira relocates it. The work still starts from zero when someone picks up the ticket. Here the trigger runs the AI PR pipeline against your actual codebase, so what lands in your queue is a branch with a first pass at the change, ready to review, edit, or close.
The sweep stamps the cluster when it fires and never fires it again, so a theme that keeps collecting votes after the PR exists does not spawn duplicates. You opt in per project and choose the number, from a cautious 100 down to a scrappy 2.
The output is a draft pull request on a fresh branch. It carries the cluster context and links back to the feedback, and it waits for you. Merging, closing, or rewriting it is your call, same as a PR from a teammate.
The limits
A trigger that writes code deserves clear limits. Here are the ones that matter.
The pipeline stops at a draft PR on its own branch. There is no auto-merge setting, on purpose. A demand count is evidence a problem matters, and it says nothing about whether a specific diff is correct.
Deduping works off submitter identity and board accounts. Fully anonymous feedback with no identifying signal can overcount or undercount a cluster, so treat the number as a strong estimate rather than a census.
Once a cluster has triggered, changing the threshold later does not re-trigger it. If the auto-drafted PR was closed and the demand keeps growing, drafting again is a manual click on the cluster page.
Small fixes and contained features come out well. A request that amounts to "rebuild the billing system" will produce a starting point and an outline of the work, and a human finishes it.
The honest objection
Agreed, and a threshold does not fix that, so this feature treats the count as a floor rather than a ranking. Deduping by person blunts the single-obsessed-user problem, you pick the number, and the worst case of a gamed threshold is one draft PR you close after a two-minute skim. If your roadmap is vision-driven and user demand is an input you weigh but never act on mechanically, leave the toggle off and keep drafting PRs by hand from the cluster page; the feature is a shortcut, and skipping it costs nothing.
FAQ
Per cluster, as unique requesters. Everyone who submitted feedback that landed in the cluster counts once, no matter how many times they wrote in, and people who upvoted a linked board post count too. The count is compared against your threshold on a recurring sweep.
Usero queues the same AI PR pipeline you can run by hand from a cluster page: it reads your connected repo, writes a fix or first implementation on a new branch, and opens a draft pull request. The cluster gets an "Auto-drafted" badge with the trigger date.
No. There is no setting that merges. The result is always a draft PR that waits for your review, and closing it unmerged has no side effects beyond the cluster keeping its badge.
Where they exist, they forward the request to an issue tracker, so the threshold creates a ticket and the engineering work still starts from nothing. This one ends in a reviewed draft PR against your repo. The request that inspired the category, on Featurebase's own board, has been open about three years without shipping even the forwarding version.
A connected GitHub repository with a selected repo, and clustering doing its normal job on your feedback. A public board helps because upvoters add to the demand count, but it is not required. The toggle and threshold live in Settings under the GitHub section.
For an early product, 5 to 10. You want the PR drafted while the demand is fresh, and reviewing an occasional unnecessary draft costs minutes. Teams with heavy feedback volume set 25 or more so only broad themes trigger.
Free tier. No credit card. Two-minute install. The AI opens the PR, you merge it.
Keep reading