Should I vibe code
Create a poll, quiz, or survey and embed it with basic response analytics
A public poll is a vote count anyone can write to. Yours is accurate until one person with a for-loop cares.
?
Their verdict, the Pro (1,000 responses) 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
Radio buttons, a POST, a bar chart. It really is one sitting, and the demo is convincing on the first afternoon. The thing that makes a poll different from every other form on this site is that a poll publishes its own results — the whole point is that the reader sees 68% and believes it. That turns an ordinary submit endpoint into a public tally, and a public tally is the one kind of user input that is worth forging for its own sake. Browser-side deduplication is a request, not a control: a cookie is deleted, localStorage is per-browser, and an IP check either lets an office through once or blocks a whole mobile carrier. Nobody needs a botnet, just curl and a loop. Underneath that sits the ordinary version of this problem, which is that the survey half quietly accumulates free text and email addresses from strangers, and the free text is rendered straight back into the one page you never hardened, which is your own results dashboard. None of this is exotic and none of it kills anybody. It is simply the difference between a chart and a number people quote, and the gap between them is the part you will not have built by Sunday.
What actually breaks
not "if". the specific failures.
- The tally, which is the product. Cookie and localStorage dedup survives one incognito window; IP dedup either admits an entire office once or blocks a whole mobile carrier, and neither of them slows down a shell script
- Your own dashboard, the first time somebody types a script tag into a free-text answer. The public widget is usually escaped carefully and the admin results view is usually not, which puts the payload in front of the one session that can edit everything
- The result nobody can date. Somebody screenshots '68% agree' for a newsletter, you fix a bug and reset the counts, and there is now no record of what the number was on the day it was quoted
- Partial responses, because a multi-question survey that saves as it goes stores the answers of everyone who reconsidered at question four — including the ones who never reached whatever consent line you put at the end
- Branching logic, once the question tree stops being a list. A UI that lets you draw jumps lets you draw a cycle and an unreachable branch, and both strand a respondent on a page with no way forward
- The embed endpoint, which by design accepts posts from any origin, so the CORS setting you loosened to debug an iframe is now the whole access policy
- Response volume, which is precisely what the commercial tiers meter. A poll that gets picked up writes a row per vote against a database sized for a launch announcement
- The archive. A survey that ran for a year is a table of other people's opinions attached to their email addresses, with no expiry and nobody who remembers it exists
Is that you?
the verdict is a default, not a law
- The audience is internal, or small enough that you would recognise a rigged result on sight
- Nothing downstream acts on the percentages — no pricing decision, no editorial claim, no press quote
- The poll collects an answer and nothing else: no email address, no free text, no 'tell us more'
- It runs for a fixed campaign with a switch-off date written down before launch
- The result is displayed publicly and anyone has a reason to want a particular answer to win — a contest, a vote, an award, an editorial position
- The number will be cited anywhere as a finding, a statistic or evidence of what your audience thinks
- Free-text answers are rendered anywhere in an admin view without escaping
- Responses feed a marketing list, which makes the consent record part of the build rather than an afterthought
- The questions wander into health, money or politics, which changes what the stored answers are
If you build it anyway
the checklist, then the prompt that enforces it
- Decide what the tally is worth before writing the vote endpoint. If the answer is 'someone would rig this', you need a session or an account, and browser-side deduplication is decoration you should not pretend is a control.
- Rate-limit per IP and per poll, cap total votes per window, and add a bot check to the submit path in v1 rather than after the first spike.
- Escape free text everywhere, and treat the admin results page as the hostile surface it is. That page renders attacker-supplied strings to the one session with delete rights.
- Snapshot the counts on a schedule and keep the history. When a number is challenged or reset, the archive is the only way to say what it was on the day it was quoted.
- Validate every submission server-side against the question definition — option ids, required answers, one response per question — instead of trusting the shape the widget produced.
- Pin CORS to the domains you actually embed on, and set a real Content-Security-Policy on the widget so an embed on somebody else's page cannot be pointed at your endpoint from anywhere.
- Give responses a deletion deadline at write time, and expire abandoned partials sooner than completions — those people did not finish, and you should not keep them as if they had.
- Keep the email capture a separate, recorded decision: what was consented to, when, and from which URL. A survey response and a mailing list subscription are two different agreements.
I am building an embeddable poll and survey widget whose results are shown
publicly. Treat the vote count as the asset, not the UI, and push back when I
ask for something on this list.
1. Ask me first whether the result is public and whether anyone would benefit
from a particular answer winning. If yes, tell me plainly that cookie and
localStorage deduplication will not hold, and design for sessions or
accounts instead.
2. Build the submit endpoint before the chart: server-side validation of every
option id against the stored question definition, per-IP and per-poll rate
limits, a total cap per window, and a bot check in the first version.
3. Escape free-text answers on output everywhere, and specifically in the admin
results view. Assume the survey response is an XSS payload aimed at my own
session, and show me where you escaped it.
4. Snapshot vote counts on a schedule and keep the history, so I can answer
"what did the number say on the day someone screenshotted it".
5. Pin CORS to my real domains and set a Content-Security-Policy on the widget.
Do not leave the endpoint open to any origin because it is embeddable.
6. Store partial responses only if I ask. If I do, expire them sooner than
completed ones and tell me the retention window you chose.
7. Give every response a deletion deadline at write time, and write the job
that enforces it before the results dashboard.
8. Keep email capture as a separate step with its own record — purpose,
timestamp, source URL. Do not bundle a mailing-list subscription into
submitting an answer.
9. If I ask for branching logic, validate the question graph on save: no
cycles, no unreachable questions, every path ends.
10. Out of scope unless I say otherwise: A/B testing questions, CRM sync,
and anything that presents these percentages as research. Say so, and
remind me Opinion Stage is $32 a month if the number is going to be quoted.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 percentage is going to be shown to strangers or repeated as a finding. $32 a month is not buying radio buttons — you can have those tonight. It buys deduplication that has been attacked before, an escaped admin view, response ceilings that fail visibly instead of silently, and a consent record that arrives with the form rather than being retrofitted. If the poll is a bit of fun on your own newsletter, build it. If the number ends up in a slide, buy it.
$32/mo is cheaper than your weekend.
This comes apart more cleanly than most things on this site: the poll definition is JSON, the responses are a CSV, and the commercial tools all import both. Take the count history with you as well as the current totals, because the totals alone cannot be reconciled against anything anybody published. The part that does not travel is consent — whatever you recorded about why you hold each email address has to move with the address, or you arrive at the new provider with a list you cannot lawfully send to. Then delete the responses you no longer have a reason to keep, which on an old survey is most of them.
Actively developed open-source survey platform with logic jumps, self-hostable so responses stay on infrastructure you control.
Long-running open-source survey engine with question types, quotas and anonymity handling already thought through.
Questions
It's a poll on a blog. Who is realistically going to rig it?
Nobody, until the poll is about something. The pattern is boring and consistent: a poll about which pastry is best is safe forever, and a poll deciding a shortlist, an award, a name, or which vendor readers prefer attracts exactly one motivated person with a terminal. The tell is whether a specific answer is worth anything to anyone. If it is, you need a session or an account, and no amount of client-side deduplication substitutes.
Why does the admin dashboard get singled out as the security problem?
Because of who is looking at it. The public widget usually gets escaped properly, since that is the code you stared at. The results page is a private page you wrote quickly for yourself, it renders every free-text answer a stranger submitted, and the session viewing it can edit and delete everything. That combination — untrusted input, unhardened output, maximum privilege — is why free-text survey fields are worth more to an attacker than the votes are.
Is a poll response really personal data?
The answer on its own often is not. What makes it personal data is everything you store beside it: the IP you kept for deduplication, the cookie id, the email address on the lead-capture step, the referrer showing which article they were reading. Under GDPR that bundle is personal data whether or not you asked for a name, which means it needs a lawful basis, a retention limit and reasonable security — and the retention limit is the one people skip, because survey tables are the classic thing nobody ever deletes.
- GDPR Art. 5 — principles relating to processing of personal data (EU)
- GDPR Art. 32 — security of processing (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.
Everything else here is judged on what it stores. A calculator is judged on the number it told a stranger.
A form that emails a result to whatever address it is handed is an open relay with your logo on it.
Survey answers are other people’s opinions with their identity attached. Store them like it.
last reviewed 2026-08-05 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice