Should I vibe code
Collect feature requests, merge duplicates, publish statuses, and maintain a roadmap
A public feedback board is a public spam target with a voting mechanism attached.
?
Their verdict, the Starter price and the build-time estimate come from their entry, MIT-licensed. Checked 2026-08-03.
?
Our verdict, the regret score and everything below it. Editorial and unsponsored — nobody can pay to be moved.
The honest answer
why the verdict is what it is
Posts, votes and statuses are a small CRUD app. The part people forget is that anything public and writable gets abused, so moderation is a feature, not an afterthought.
What actually breaks
not "if". the specific failures.
- A public roadmap, which customers read as a commitment regardless of the disclaimer next to it
- Duplicate requests, which arrive constantly in different words and fragment the vote count that was meant to prioritise
- Votes as a decision procedure, since the loudest customers are not the most numerous and neither is the same as most valuable
- Abandoned requests, where 'planned' from two years ago is worse than never having said anything
- Public visibility of who asked for what, which can expose one customer's plans to another
A feature gets marked Planned because it genuinely was. Priorities move, as they do, and the card stays. Eighteen months later a prospect finds it during evaluation, takes it as a roadmap commitment, and signs partly on that basis. The first support conversation after onboarding is about when it ships. Nobody lied. A status was set once and never revisited, and a public board turns every stale status into a promise you did not know you were still making.
Is that you?
the verdict is a default, not a law
- The board is internal and customers never see a status
- Statuses are reviewed on a schedule and stale ones expire automatically
- Votes inform a human decision rather than making it
- A public roadmap has no process for revisiting statuses
- Duplicate merging is unimplemented and votes are used to prioritise
- Customer names or company details are visible to other customers
- You would not be comfortable being held to every status on the board
If you build it anyway
the checklist, then the prompt that enforces it
- Treat every public status as a promise, because customers will. If you cannot commit, use fewer statuses — 'considering' and 'shipped' is an honest board.
- Expire statuses automatically. Anything marked Planned that has not moved in a quarter reverts and prompts a human.
- Build duplicate detection and merging early, preserving the vote and the original wording of both.
- Weight votes by nothing you cannot defend. Show counts, and keep the prioritisation decision explicitly human.
- Decide whether requesters are visible to each other before launch — a competitor reading your customer's feature request is a real outcome.
- Rate limit and require an account to post, because a public board is a public write endpoint.
Before you build a feature request board, apply these and push back if I ask you to break them. 1. Ask me whether this board is public. If yes, tell me that every status is read as a commitment no matter what disclaimer sits beside it, and that the most common failure is a two-year-old 'Planned' card that a prospect treats as a roadmap. 2. Implement status expiry: anything in a forward-looking state that has not changed within a set period reverts automatically and notifies a human. Do not let statuses persist by default. 3. Keep the status vocabulary small and honest. Prefer fewer states I can defend over a detailed pipeline I cannot keep current. 4. Build duplicate detection and merging before the board is opened up. When merging, preserve both original texts and combine votes without losing attribution. 5. Show vote counts but never present them as the decision. Prioritisation is a human judgement and the interface should reflect that. 6. Ask me explicitly whether requesters' names and companies are visible to other users. Default to hidden, and warn that a customer's request can reveal their plans to a competitor. 7. Require an account to post, rate limit submissions, and moderate before public display. 8. Let a requester delete their own request and their identity from it. 9. Out of scope unless I ask: changelog, in-app widgets, segment analytics, integrations with issue trackers.
That one keeps you out of trouble. For the prompt that actually builds it, canivibecodeit.com has one.
their build prompt ↗Or don’t build it
the boring option, and the way back out
$99 a month is steep and mostly buys duplicate handling and a moderation workflow. The stronger argument for buying is that a public roadmap is a commitment surface — having it run on maintained software with sensible defaults is worth more than the board itself.
Export requests, votes, statuses and merge history — the merge history matters because a merged request represents a judgement that cannot be recovered from the merged result. If the board is public, remember that closing it is itself a visible act, so plan how it ends.
Open-source customer-feedback portal with voting and status workflows.
Questions
Doesn't a disclaimer cover the roadmap commitment problem?
Not in practice. People read the status, not the fine print, and a prospect evaluating your product treats 'Planned' as information about what they are buying. The workable protection is structural — fewer states, and automatic expiry so nothing stays forward-looking without someone re-confirming it.
Why shouldn't votes decide priority?
Because they measure willingness to click, which correlates weakly with value. A handful of engaged users can outvote a silent majority, and the customer whose renewal depends on something may never open the board at all. Votes are a useful signal about what people notice; they are a poor proxy for what matters.
Every week, someone ships something they shouldn’t have.
New verdicts, the worst thing that landed in the trap, and the occasional incident report. No other email, ever.
last reviewed 2026-08-03 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice