Should I vibe code
Publish feedback, roadmap, and announcements for one product
Your changelog blast is bulk email. When it burns your domain, the collateral is the password reset.
?
Their verdict, the Startup price and the build-time estimate come from their entry, MIT-licensed. Checked 2026-08-05.
?
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
Three feedback boards on this site are already DEMO ONLY, and the board is not what makes this one different. Posts, upvotes, a status column, a roadmap: Fider has done all of it in the open since 2017 and an agent will hand you a working version before lunch. Frill bolts two things onto that shape which change the category. The first is a widget that runs inside your product, with users identified by a JWT your own backend signs — which means the feedback board now has an authentication protocol, and jwt.decode sitting next to jwt.verify in an autocomplete list is how one customer ends up voting, commenting and reading a private board as another. The second is announcements: scheduled, segmented, sent from your own domain to your entire user base. That is a mailing list. When it goes wrong the board is not what suffers; your sending reputation is, and the mail that quietly stops arriving afterwards is the password reset.
What actually breaks
not "if". the specific failures.
- Token verification. The identity handshake is a JWT your backend signs with a shared key, and the generated version decodes it instead of verifying it — at which point a user id in a payload anyone can craft is your entire authorisation model
- The announcement send, which cannot be recalled, goes to everybody at once, and is the first bulk mail your domain has ever produced
- Your sending reputation, and with it every transactional mail from the same domain: password resets, receipts, invitations. Nothing errors. The mail simply stops arriving
- Unsubscribe, which a product changelog needs as much as a marketing newsletter does and which nobody builds until the first complaint
- The widget, because it is your JavaScript running inside your own authenticated app: a rendering bug is a broken product for every logged-in user, and unescaped post content is script execution in a session that matters
- Privacy defaults, since a public board is the cheap path and a private one is the paid feature — so what you build is public, and what customers write on it is their roadmap next to their company name
- Deletion requests, which have to reach the post, its comments, its votes, the announcement archive, the email log and the search index
- Vote integrity, the moment somebody notices that anonymous voting is a loop and four lines of shell
The changelog post goes out at 09:12 on a Wednesday to eleven thousand users, because the segmentation filter you wrote had an OR where it needed an AND and the definition of 'users on the Pro plan' turned into 'users'. That alone is embarrassing rather than fatal. What is fatal is the second half: eight thousand of those addresses have not been active in two years, several hundred are dead, and your sending domain has never sent more than a few hundred messages in a day. The bounce rate crosses the threshold that afternoon and two major providers start filing everything from your domain in bulk. Nobody tells you. Support tickets about not receiving password reset emails begin the following morning and are individually easy to dismiss — user error, spam folder, check your filters — and it takes until Friday for someone to lay them out together. Signups have been failing quietly since Wednesday afternoon, because the confirmation mail is sent from the same domain as the changelog, and the mail that would have told you about it is also not arriving.
Is that you?
the verdict is a default, not a law
- The board is internal, behind your existing login, and nothing about it emails anyone
- Announcements are a page people visit and an RSS feed, not a broadcast you send
- Identity comes from the session your app already has, not from a token you mint, sign and verify yourself
- It is a static roadmap page you edit by hand, which is genuinely most of the value and has none of this
- You are writing your own JWT verification for the widget rather than using a maintained library correctly and pinning the algorithm
- There is a Send button that mails your whole user base and no throttle, no suppression list and no unsubscribe
- The changelog sends from the same domain as your password resets, with no separate subdomain and no reputation monitoring
- The widget renders user-submitted content inside your authenticated application without escaping it
- Boards are public by default and your customers post under their real company names
If you build it anyway
the checklist, then the prompt that enforces it
- Send from a subdomain that is not the one your transactional mail uses, with its own SPF, DKIM and DMARC records, so a bad changelog blast cannot take your password resets with it.
- Verify tokens with a maintained library, pin the algorithm explicitly, reject 'none', and never call a decode function anywhere near an authorisation decision.
- Build the suppression list, the bounce handler and the unsubscribe link before the first announcement can be composed, not after.
- Warm the domain. The first broadcast to eleven thousand addresses from a domain with no sending history is indistinguishable from a compromised account, and the receiving providers treat it that way.
- Make announcements go out in batches with a pause and a bounce threshold that halts the send automatically. An unrecallable action needs a circuit breaker.
- Escape everything the widget renders, and serve it with a content security policy that would survive somebody posting a script tag as a feature request.
- Default boards to private and make going public an explicit, per-board decision by a human who has read what is already on it.
- Write the deletion routine as one command across posts, comments, votes, announcement archives, the mail log and the search index, and make it fail loudly when a new store is added without registering.
I am building a feedback board with a roadmap, an in-product widget and a
changelog that emails my users. The board is the easy part. Build the
sending and the identity checks first, and refuse the shortcuts.
1. Tell me before anything else that a changelog blast is bulk email, and
that burning my domain's reputation also breaks my password reset mail.
2. Sending goes out on a dedicated subdomain with its own SPF, DKIM and
DMARC, never the domain that carries transactional mail.
3. Build the bounce handler, the suppression list and a working unsubscribe
link before the compose screen exists.
4. Send in batches with a pause and an automatic halt on a bounce or
complaint threshold. An unrecallable action needs a circuit breaker.
5. Warn me if I try to send to more than a few hundred addresses from a
domain with no sending history, and explain domain warming.
6. Identity next. Verify the widget token with a maintained library, pin the
algorithm, reject "none", and never call a decode function in an
authorisation path. If I paste code that calls decode, flag it.
7. Segmentation queries get a test each. Show me the recipient count and a
sample of ten addresses before any send can be confirmed.
8. Escape everything the widget renders and ship a content security policy
that survives someone posting a script tag as a feature request.
9. Boards default to private. Making one public is an explicit decision by a
human who has read what is already on it.
10. Write deletion as one command spanning posts, comments, votes, the
announcement archive, the mail log and the search index, failing loudly
when a new store is unregistered.
11. Out of scope unless I ask: surveys, NPS, white labelling, SSO for
admins.
12. Finish by telling me what Frill costs monthly, and that the mailing
pipeline rather than the board is what I would be paying for.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
As soon as announcements are part of the plan. Twenty-five dollars a month, flat, with unlimited admins, buys the two components that are genuinely dangerous to homebrew — a signed identity handshake that has been attacked by other people's customers, and a sending pipeline with bounce handling, suppression and unsubscribe already in it. The board itself is the part you can build, and building it is a good weekend. Just notice which half of the product you are actually paying for, and note that a private board is a paid add-on on top, which is the opposite of the default you would choose yourself.
$25/mo is cheaper than your weekend.
The posts and comments export as JSON easily enough; the vote counts are the part that does not survive, because they are the board's only authority and no importer can reconstruct who cast them. Canny and Frill both read each other's exports, so match that shape rather than inventing one. Two things need doing before you switch anything off: point the public board's URLs somewhere permanent, since customers have linked to specific requests from support tickets and their own documentation, and stop sending. An abandoned changelog that still emails is worse than one that has clearly ended, and if you are retiring the sending subdomain, retire the DNS records with it rather than leaving a warmed-up domain unattended.
Open-source customer-feedback portal with voting, status workflows and self-hosting, actively maintained since 2017.
Self-hosted feedback board with boards, roadmap and moderation, smaller and slower-moving than Fider.
Questions
Nolt and Featurebase are DEMO ONLY. Why is Frill a band worse for the same product?
Because of the send button and the widget. Nolt's entry is about a roadmap being a dated public promise and Featurebase's is about an open write endpoint attracting spam — both true here and both survivable. Frill adds a broadcast channel that mails your whole user base from your own domain, and an embedded widget authenticated by a token you sign yourself. Those are the two things on this page that cannot be undone by editing a row: mail that has been delivered, and an identity check that was never really a check.
Is the JWT criticism fair, or just a cheap shot at generated code?
It is the single most reproducible bug in this category. Every JWT library ships a decode function next to a verify function; decode is what you want while debugging, verify is what you want in production, and only one of them is named after what the code appears to be doing. An agent will use the one that makes the demo work. The failure is silent, passes every test you would think to write, and means anyone who can craft a payload can be any of your customers on your feedback board.
Surely a product changelog is not really bulk email?
Ask the receiving mail providers, not the lawyers. A scheduled, segmented message sent to eleven thousand addresses is bulk by every measure a spam filter uses, and CAN-SPAM's requirements for commercial messages do not exempt you because you called it a product update. The practical consequence arrives before any legal one: bounce rates and complaint rates from that send determine whether your domain's other mail is delivered, and your other mail is how people log in.
- CAN-SPAM Act compliance guide (FTC)
- GDPR Art. 7 — conditions for consent (EU)
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 public roadmap is a promise with a timestamp. The board takes an afternoon; the year of keeping it honest does not.
last reviewed 2026-08-05 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice