Should I vibe code
Publish a feedback board with voting, comments, statuses, and a roadmap
A public roadmap is a promise with a timestamp. The board takes an afternoon; the year of keeping it honest does not.
?
Their verdict, the Essential price and the build-time estimate come from their entry, MIT-licensed. Checked 2026-08-04.
?
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, upvotes and a status column are a small CRUD app, and an agent will hand you a convincing one in an afternoon. That part is not in dispute, and the spam argument is already made next door in the Canny and Featurebase entries. What is specific to a roadmap board is that everything on it is public and dated. "Planned" is a commitment in writing, a vote count is an argument your customers will make back at you, and a board whose newest "In progress" item is fourteen months old says more about your company than your homepage does. Build it if you will run it. The version that hurts is the one launched in week one and stopped being read in week nine — still embedded on the pricing page, still collecting requests, still answering nobody.
What actually breaks
not "if". the specific failures.
- The roadmap column, which is a dated public promise and the part of your product your competitors read most carefully
- Your attention — the board outlives the enthusiasm that created it, and a stale "Planned" list reads as neglect rather than transparency
- The vote counts, which are the board's entire authority and the one thing no migration preserves
- Deduplication: the same request arrives eleven times in eleven phrasings, and merging without losing the votes or the original posters is the feature nobody builds first
- Notification email, where one busy thread becomes a mailshot from a domain that has never sent anything before
- Identity, because a board with no login is a spam target and a board with a login is a second account system your customers now have to care about
- The embed, which is your board inside an iframe on your marketing site — so its downtime is your homepage's downtime, in front of the people deciding whether to buy
- Deletion requests, which have to reach the post, its comments, its votes, the email log and the search index
Is that you?
the verdict is a default, not a law
- The board is internal, or public and read-only, with requests arriving through a channel a human already reads
- Triage is somebody's actual weekly job, with a name against it
- You would be comfortable seeing any item on it screenshotted, because it will be
- Statuses describe what you are doing rather than when it ships
- Anyone can post with no identity check at all and the board is indexed under your marketing domain
- You are launching it to look responsive rather than to change what you build
- Vote counts will drive roadmap decisions but nobody will ever look at who is voting
- You cannot say what the board should look like in eighteen months, including the part where things get closed
If you build it anyway
the checklist, then the prompt that enforces it
- Publish statuses, not dates. "In progress" is a fact you can defend; "Q3" is a commitment made by a version of you who had not met Q3 yet.
- Build export before the board is public: posts, comments, votes, voters and statuses as JSON. Vote counts are the asset and they are the first thing a migration loses.
- Make merge a first-class operation that preserves both vote sets and both authors. Without it the board fragments into duplicates within a month and the counts stop meaning anything.
- Require some identity to post — SSO from your own app is the clean version — and rate-limit posts, comments and votes per account and per IP from the first commit.
- Send digests, never per-reply email, with a per-person daily cap and a working unsubscribe. A young board on a young domain can burn its sending reputation in one popular thread.
- Give closure a workflow: a "not planned" status with a written reason, and an archive rule for anything untouched for a year. A board only stays honest if things are allowed to leave it.
- Treat the embed as third party. Serve it from a subdomain that is not your app, and make the host page degrade to a plain link when it fails rather than rendering a broken panel on your pricing page.
I am building a public feedback board with voting, comments, statuses
and a roadmap view. The failure here is not a crash — it is a board that stays up,
fills with duplicates and quietly stops being read. Build against that, and push
back when I ask for things in the wrong order.
1. Before any UI, define the lifecycle of a post: open, planned, in progress,
shipped, not planned, archived. Every status needs an exit. Refuse to add one
that has no way out.
2. Build export second: posts, comments, votes, voter identities, statuses and
timestamps as JSON, runnable from the command line. The vote counts are the
only thing here I cannot recreate.
3. Then merge. Two posts become one, both vote sets are preserved, both authors
are notified, and the loser redirects rather than 404s. Write the test for the
voter who voted on both.
4. Only then the board UI.
5. Require identity to post or vote — SSO from my app if I have one, verified
email otherwise. Never allow anonymous writes on an indexed domain.
6. Rate-limit posts, comments and votes per account and per IP, and add a
moderation hold state before anything becomes publicly visible.
7. Email is digest-only, with a per-person daily cap and a real unsubscribe. If I
ask for per-reply notifications, tell me first what that does to a sending
domain with no history.
8. The roadmap renders statuses. If I ask for target dates, push back once and
say plainly that a dated public roadmap is a written commitment I will be held
to by people who screenshot it.
9. Deletion means the post, its comments, its votes, the email log and the search
index — enumerated in code, so a new table joins the same list.
10. The embed is an iframe on a separate subdomain with a strict CSP, and the
host page degrades to a plain link when the board is down.
11. Out of scope, and say so: analytics, changelog, integrations. Then tell me
what Nolt costs and ask who is triaging this board in month six.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
The moment the board is customer-facing and you are not the person who will read it every week. Roughly $29 a month buys moderation tooling, deduplication, SSO, an embed that stays up and — quietly the biggest item — a board that keeps working during the two months you are busy shipping. Building it was never the expensive part. Running it is, and that bill arrives either way.
$29/mo is cheaper than your weekend.
Own the export from day one and the board stays portable: posts and comments as markdown with stable ids, votes as a voter-to-post CSV, statuses as a column. Fider imports something close to that shape and so does every hosted competitor. The part with no clean exit is the URL — a board linked from your docs, your release notes and a year of support replies cannot simply move, so put it on a path you control and keep the redirect alive after you leave.
Open-source customer-feedback portal with voting and status workflows.
Questions
canivibecodeit says YES. Why are you harsher?
Because they are answering whether an agent can build a feedback board, and it plainly can — this is one of the more tractable CRUD apps in the set. Our question is whether you should run one. A board is a public, dated record of what you said you would do, kept in front of customers, indefinitely. That is an ongoing commitment rather than a build, and it is the part that goes wrong.
What actually kills a self-built board?
Duplicates and silence, in that order. With no merge operation the same request appears eleven times and the vote counts stop meaning anything, so the board stops informing decisions, so nobody looks at it, so nobody replies — and a public board where nothing has been answered since spring is a worse advert than no board at all.
Can I just make it read-only?
Yes, and it is a genuinely better project. A published roadmap with no write endpoint has no spam problem, no moderation rota, no second account system and no deletion workflow — you generate it from whatever tracker you already use. You lose the votes, which is a real loss, and you lose the entire operational tail, which is a bigger win than it sounds.
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.
A public feedback board is a public spam target with a voting mechanism attached.
An open post box on your own domain is a spam farm with your favicon on it.
A support inbox that quietly loses one email in a hundred is indistinguishable from a company that ignores you.
last reviewed 2026-08-04 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice