Should I vibe code
Run a feedback portal, changelog, roadmap, and lightweight support widget
An open post box on your own domain is a spam farm with your favicon on it.
?
Their verdict, the Growth 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, votes, statuses and a changelog is a CRUD app, and an agent will hand you a convincing one before lunch. The part that does not come in the box is that a public write endpoint on an indexed domain is found by link-spam bots long before it is found by a customer, and that moderation is not a feature you build but a rota you staff. You will have the board. What you will not have is anyone whose job it is to read it on a Tuesday in March.
What actually breaks
not "if". the specific failures.
- Unauthenticated posting, within about a week — a public form on an indexed domain is a link-building target before it is a feedback channel
- Moderation, which is a rota rather than a feature, and there is not one
- A customer pasting an order number, their email address and a screenshot with a session token visible in the URL bar into a public thread
- Deletion, which removes a post from your database and not from Google’s cache, your own RSS feed, or the notification email already sent to forty subscribers
- The roadmap column, the moment a competitor reads it as intelligence and a customer reads a delivery date into it
- Vote counts, once someone realises voting is anonymous and a loop is four lines of shell
Is that you?
the verdict is a default, not a law
- Posting requires being logged into your product, so every author is already an account you can identify
- The board is internal, or behind the same auth as the app
- You have decided who moderates it and how often before it launches, and written that down
- It is one board, not a board plus a changelog plus a roadmap plus a helpdesk widget
- Anyone with the URL can create a post and the board lives on your marketing domain
- Support tickets will end up in it — and they will — while the board is public
- You are also building the helpdesk widget, which is a different product wearing the same clothes
- Nobody has agreed to read it every week, because an abandoned public board is worse marketing than no board
If you build it anyway
the checklist, then the prompt that enforces it
- Require authentication to post. Voting can stay anonymous; writing cannot. This single decision removes most of this entry.
- Build the moderation queue and the delete path before the public board. Deletion first, display second.
- Keep it `noindex` until moderation exists, and off your primary marketing domain — a spammed subdomain is recoverable, a spammed root domain is a project.
- Never render user text as HTML, and strip links from posts until an account has some history.
- Rate limit per account and per IP, and alert on burst posting rather than finding out from Search Console.
- Treat submitter email addresses as personal data: never render them publicly, and write the deletion path that removes a person’s posts, comments and votes in one operation.
- Put a visible line on the board saying it is not a support channel, then route the support requests that arrive anyway to somewhere private.
I am building a public feedback board with voting, statuses and a changelog. Apply these and argue when I try to open it up.
1. Authentication to post, from the first commit. Anonymous voting is fine;
anonymous writing is not. If I ask for anonymous posting to reduce
friction, tell me what a public write endpoint on an indexed domain
attracts within a week and make me confirm.
2. Build the moderation queue and the hard-delete path before the public
board renders anything. Deletion before display.
3. Deletion must remove the post, its comments, its votes and any attachments
in one operation, and must also handle “delete everything by this person”.
Write that as a single tested function.
4. `noindex` and `nofollow` until moderation exists, and host the board on a
subdomain rather than my root marketing domain. Explain why that choice is
hard to reverse.
5. Never render user-submitted text as HTML. Escape everything, strip links
from accounts with no history, and show me where the escaping happens.
6. Rate limit per account and per IP, and add an alert on burst posting. I
should learn about spam from a notification, not from search results.
7. Email addresses attached to posts are personal data: never render them in
public output, never include them in an export that a non-admin can
trigger, and support erasure on request.
8. Assume support requests will arrive on the board. Add a one-click way for a
moderator to move a post to a private channel, and never let a post
containing an order number or an email stay public by default.
9. Statuses are commitments. Do not add dates to the roadmap, and tell me why
a public “Q3” is a promise a customer will quote back to me.
10. Out of scope until I say otherwise: the helpdesk widget, live chat, AI
replies, single-sign-on into the board. Each is its own product.
11. Before we finish, ask me who moderates this and how often. If I do not
have an answer, say so in the README.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
If the board is public and customer-facing, rent it. Around $29 a seat buys spam handling, moderation tooling, an erasure path and — the underrated part — somebody else’s domain absorbing the abuse traffic. Build it only when the board sits behind your product’s existing login, where the abuse surface simply does not exist.
$29/mo is cheaper than your weekend.
Export posts, comments, votes and their authors as JSON on day one, with stable identifiers and original timestamps — Canny, Featurebase and Fider all import something like that shape, and a board without its vote history is just a list of opinions. Keep the board on a subdomain so shutting it down is a DNS change and a redirect rather than a hole in your main site’s URL structure.
Open-source customer-feedback portal with voting and status workflows.
Questions
We are tiny. Would spammers really bother with our feedback board?
They are not targeting you, they are targeting any domain with an open write endpoint and an indexable output page, and that search is automated and continuous. Small does not help; being indexed and unauthenticated is the whole qualification. The cheapest fix is not a spam filter, it is requiring a login to post.
What is actually wrong with putting the roadmap in public?
Nothing, until a status becomes a date. “Planned” is a signal; “Q3” is a sentence a customer will read to you during a renewal conversation, and a competitor will read as a schedule to beat. Featurebase does not solve that either — but a bought board makes the status vocabulary someone else’s deliberate design decision rather than a dropdown you added at midnight.
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.
A public roadmap is a promise with a timestamp. The board takes an afternoon; the year of keeping it honest does not.
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