Should I vibe code
Surveys, workflows, feedback programs, and enterprise integrations
“Responses are anonymous” is an engineering claim. Your access log, invite token and timestamps disagree.
?
Their verdict, the Professional 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
Everyone underestimates this one the same way: they price the form and forget the promise. Question types, branching and a results table are a competent weekend, and if the survey is "what should we order for lunch" you are done. Alchemer is not sold for that. It is sold to run feedback programmes across an organisation — engagement surveys, exit interviews, patient experience, supplier audits — and the sentence that makes those work is "your responses are anonymous". That sentence is an engineering claim, and it is one your build will break by accident: the access log holds the IP, the invite token maps back to the email you sent it to, the timestamp plus a department field identifies the only person in that department, and the free-text box is where someone describes their manager in terms they would never sign. You cannot un-promise it afterwards and you cannot un-collect the responses. Build a survey; do not build an anonymous one unless you can explain, table by table, why it is.
What actually breaks
not "if". the specific failures.
- Anonymity, which almost never fails through the response table — it fails through the invite token, the access log, the timestamp, or a demographic question with one person in the bucket
- The free-text box, where someone names a colleague or describes a medical reason for leaving, and your schema cannot tell that answer from a satisfaction rating
- Response integrity, the first time a survey carries an incentive: duplicate submissions, one person and forty devices, and a bot that finishes a fifteen-minute survey in nine seconds
- Branching logic, which is a small interpreter you did not know you were writing, and which strands respondents in a page with no valid next step
- Partial responses, because whether a half-finished survey counts changes every number in the report and nobody decides it up front
- Accessibility, since custom radio and slider widgets are unusable with a screen reader, and a public-sector or university survey has a legal obligation there
- The results, quietly: no randomisation, so option order biases every ranking, and the average of a five-point scale gets treated as a fact
- Deletion and retention, once responses are joined to a contact list, an email log and an export that someone downloaded to a laptop in March
HR runs the engagement survey through the thing you built, because it was free and the vendor renewal was in doubt. Three hundred responses, promised anonymous on the landing page in a sentence you wrote. Then a director asks a reasonable-sounding question — how did the Manchester office score — and someone opens the responses table to filter. The office field is there, because it was needed for the report. So is the submitted-at timestamp, and so is the invite token column, which exists because you needed to stop people answering twice and which maps one-to-one to the mailing list you imported. Nobody has to write SQL to deanonymise anything; two filters and a sort are enough, and one of the free-text answers describes a specific conversation with a specific manager. The incident is not that the data leaked. It is that the promise was never true, and three hundred people made decisions about what to write based on it.
Is that you?
the verdict is a default, not a law
- The survey is genuinely low-stakes, the results are not attributed, and nobody has been promised anonymity
- You are collecting from people who know exactly who you are and expect to be identifiable
- It runs once, the responses are exported and the whole thing is deleted
- You self-host LimeSurvey or Formbricks rather than writing a survey engine from scratch
- The word anonymous or confidential appears anywhere in the invitation
- Respondents are employees, patients, students, or anyone with a power relationship to whoever reads the results
- There is an incentive attached, which turns response integrity into an adversarial problem overnight
- A public body, university or regulated employer is running it, where accessibility and retention are obligations rather than niceties
If you build it anyway
the checklist, then the prompt that enforces it
- Decide what anonymous means before writing schema, then enforce it structurally: no IP in the access log for the response endpoint, invite tokens hashed and destroyed at submission, timestamps rounded to the day, and demographic combinations with fewer than five respondents suppressed in every report.
- If you cannot enforce all of that, do not use the word. "Confidential — your name is not shown to your manager" is an honest promise you can actually keep.
- Treat free text as the sensitive column. It is where health, grievances and names arrive uninvited, and it should have its own retention clock and its own redaction step before anyone reads a report.
- Build the survey engine on top of standard form controls with real labels and fieldsets. A custom slider that a screen reader cannot operate excludes exactly the respondents whose feedback the programme exists to capture.
- Randomise answer order by default and record the order shown with each response. Otherwise option-order bias is baked into every result and invisible.
- Decide the partial-response rule before launch — counted, discarded, or reported separately — and write it into the export. Deciding it afterwards means deciding it in whichever direction flatters the number.
- Rate-limit and fingerprint the response endpoint if anything is being given away. Incentivised surveys attract deliberate fraud, not accidents.
- Write the deletion and export path first, covering responses, contacts, invitations, email logs and any file uploads, and put a retention date on the survey at creation.
I am building a survey tool that will be used for organisational feedback. The failure I care about is promising anonymity and not delivering it. Treat that as a schema problem, not a copy problem, and argue with me if I blur it.
1. Before any code, ask me one question: will any invitation say "anonymous" or
"confidential"? Do not proceed until I answer. The answer changes the data model.
2. If the answer is anonymous, enforce it structurally. The response endpoint logs no IP
and no user agent. Invite tokens are stored hashed and deleted at submission. Submitted
timestamps are rounded to the day. Enumerate every column that could identify someone
and show me the list before writing the table.
3. Add a k-anonymity guard to reporting: any cross-tab bucket with fewer than five
respondents is suppressed, in the UI and in the export. Build it with the report, not
after somebody asks for a filter.
4. If I ask for both anonymity and per-respondent follow-up, refuse and explain that those
are mutually exclusive, then offer confidential-but-identified as the honest option.
5. Free-text answers go in their own table with their own retention date. Assume they will
contain names, health details and grievances, because they always do.
6. Write the deletion and export path before the builder UI: responses, contacts,
invitations, email logs and uploads, in one operation, with a test.
7. Every survey gets a retention date at creation. No indefinite default.
8. Render questions with native form controls, real labels, fieldsets and legends. No
custom radio widgets, no div-based sliders. Test one page with a screen reader before
building the second page type.
9. Randomise answer order by default and store the order shown alongside each response.
10. Decide the partial-response rule with me before launch and encode it in the export.
11. If there is any incentive, rate-limit per IP and per token, add a bot check, and flag
completions faster than a floor time rather than silently accepting them.
12. Branching logic is an interpreter. Validate at save time that every path reaches an end
page, and refuse to publish a survey with an unreachable or dead-end question.
13. Deliberately out of scope unless I ask again: panels, quota management, workflow
automation, CRM integrations and multilingual surveys. Then tell me what an anonymity
failure costs compared with a survey licence.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
Anyone in an organisation is being asked to be candid. At $165 a seat this is not a cheap product, and that is rather the point — what the money buys is somebody who has already answered the anonymity, accessibility, retention and response-fraud questions, and who signs a contract saying so, which is the thing an employer needs before it emails three hundred staff. If the budget genuinely is not there, self-hosted LimeSurvey has been doing this for twenty years and is a far better starting point than an empty repository.
Export is the whole plan and it has to include the questionnaire, not just the answers. A CSV of responses without the question text, option order, branching rules and the version of the survey each respondent actually saw is a spreadsheet nobody can interpret in two years. Dump the survey definition as JSON alongside every response set, keep the anonymisation decisions recorded with them, and prefer a format LimeSurvey can import. And write the destruction step into the same job: the honest end state for most feedback programmes is not archived forever, it is deleted on schedule.
Long-running open-source survey platform with branching, quotas, panels and anonymised response modes already implemented.
Open-source surveys and experience management.
Open-source form builder and collection backend.
Questions
We already have Typeform, Paperform and Fillout. What makes this one different?
Who is answering, and what they were told. Typeform is a lead-capture form with good taste; Fillout's problem is that someone eventually adds a medical question to an event signup. Alchemer's problem arrives on day one, because it is bought to run programmes where the respondent has a power relationship with the reader — employees, patients, students — and the whole method depends on a promise of anonymity. That promise is enforced or broken in your schema, not your copy.
How do surveys actually get deanonymised?
Almost never by someone reading the response table's name column, because there isn't one. It happens through the joins nobody counted as identifying: the invite token that maps to the mailing list, the IP in the web server log, the submitted-at timestamp next to a Slack message, and demographic questions that narrow to one person — a department, a tenure band and a location is frequently enough. Which is why the defence is structural: hash and destroy tokens, do not log the IP, round the timestamp, and suppress small cross-tabs before anyone can filter on them.
Is accessibility really a risk item or is it a nice-to-have?
For a public body, a university or a large employer it is an obligation, and it is also the thing hand-built survey UIs fail hardest. Custom radio buttons made of divs, sliders with no keyboard handling and progress bars announced as nonsense make the survey unusable for exactly the respondents a feedback programme most needs to hear from. Native form controls with proper labels cost nothing and are the single highest-value guardrail in the list.
- GDPR Art. 5 — principles relating to processing of personal data (EU)
- GDPR Art. 9 — processing of special categories of personal data (EU)
- GDPR Art. 32 — security of processing (EU)
- Section508.gov — laws and policies on accessible ICT (US)
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.
One question at a time means storing answers from people who thought about it and decided not to submit.
You never decided to store health data. A dropdown someone added to an event signup decided it for you.
LimeSurvey is GPL — don't clone it, run it. Then explain to the ethics board where the responses actually live.
last reviewed 2026-08-04 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice