Should I vibe code
Hosted open-source surveys with logic, quotas, privacy, and reporting
LimeSurvey is GPL — don't clone it, run it. Then explain to the ethics board where the responses actually live.
?
Their verdict, the Basic 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
Start with the thing nobody says out loud: LimeSurvey is GPL and has been for twenty years, so the correct consolation build is a compose file, not a survey engine. Whatever you write will be a worse version of a project that already has quotas, randomisation, forty question types, expression-based branching and eighty translations, and it will not have any of them by Christmas. Once you accept that, the real question stops being code and becomes responsibility, because what Cloud actually sells is the answer to "where is the data". Their customers are universities, health services and public bodies whose ethics submissions name a hosting region, a retention period and an anonymity guarantee, and Cloud is a European company offering a choice of seven regions with an upgrade path that does not take the survey offline mid-fieldwork. Self-hosting swaps a coding problem for a custodial one: you become the named processor for free-text answers that respondents wrote believing nobody could trace them, on a PHP application whose patches are now your Tuesday evening.
What actually breaks
not "if". the specific failures.
- Anonymity, the moment token tables and response tables share a database and somebody writes a join for a perfectly reasonable reason. The promise on the consent page is not enforced by anything except a schema decision
- Free-text answers, which are where respondents put their manager's name, their diagnosis, or the incident they were told the survey was about
- Partial responses, which the engine has to persist without a login and which your version will lose on a redeploy halfway through fieldwork
- Quotas and branching, which look like if-statements and are actually a small expression language with an evaluation order that matters
- The public endpoint, which accepts uploads from strangers and is the first thing scanned once the URL is on a recruitment poster
- Patching, forever: PHP and MySQL under a public form, on a box where nobody has agreed whose job the CVE mail is
- Backups, discovered on the day a table is corrupted and the cohort you surveyed has already dispersed — nobody answers the same survey twice
Fieldwork closes on a Friday with 2,100 responses from an anonymous staff wellbeing survey, promised in writing to be untraceable. On Monday a senior manager asks, informally, whether it is possible to see which department the harshest free-text comments came from. It is: the invitation tokens and the responses live in the same database because that is what the default schema does, and a two-line join answers the question in about four seconds. Nobody has to be malicious for this to end badly — a curious analyst, a subpoena, or a backup restored to a laptop is enough. The consent statement said anonymous, the ethics approval said anonymous, and the only thing that ever made it true was a configuration choice made in the first hour by whoever set the instance up.
Is that you?
the verdict is a default, not a law
- You are running the real LimeSurvey rather than something you wrote that resembles it
- You already operate PHP and MySQL in production, with backups you have actually restored from
- The surveys are internal, non-anonymous and low-stakes — a lunch poll, a training sign-up, an internal preference form
- No ethics approval, contract or consent statement makes a promise about where the data lives or who can re-identify it
- The survey is described to respondents as anonymous or confidential
- It carries an ethics approval, an IRB submission or a data-processing agreement naming a hosting region
- Responses could include health, employment-grievance or child-related free text
- Fieldwork has a fixed window and the cohort cannot be re-surveyed if the data is lost
- This would be the first internet-facing PHP application you are responsible for patching
If you build it anyway
the checklist, then the prompt that enforces it
- Do not write a survey engine. Run the GPL one, or Formbricks, or HeyForm. Yours will not have quotas, expression-based branching or forty question types, and those are the features that make a survey a survey.
- If a survey is anonymous, separate the invitation tokens from the responses at the storage level, not the query level — different database, different credentials, no path that can join them.
- Decide retention before fieldwork opens, write it into the consent text, and implement the deletion job at the same time. "We will delete it later" is the promise most often broken by accident.
- Back up before every campaign and restore into a scratch instance once, in advance. Responses are not reproducible and respondents will not answer twice.
- Put the instance behind TLS you did not configure by hand, keep uploads off the application server, and subscribe to the project's security announcements before the first invitation goes out.
- Pick and record the hosting region deliberately, because it is a claim you have probably already made in writing to somebody who will check.
- Test the survey on a phone, on a screen reader, and with the back button. Respondent drop-out is a data-quality problem, not a UX nicety.
I am considering running my own survey platform instead of paying for hosted
LimeSurvey. Start by talking me out of building one.
1. Say this first and plainly: LimeSurvey is GPL and self-hostable, so the build
here is a deployment, not a survey engine. Formbricks and HeyForm are the
same answer. Continue only if I explicitly say I want my own engine anyway.
2. If I am running theirs, the work is custodial rather than technical. Backups
first, with a restore into a scratch instance tested before a single
invitation goes out. Responses cannot be re-collected.
3. Ask me one question before anything else: is any survey described to
respondents as anonymous? If yes, separate invitation tokens from responses
at the storage level — separate database, separate credentials, no code path
that can join them — and tell me the default schema does not do this for me.
4. Set retention and the deletion job at the same time as the consent text, and
run the job on a schedule from day one rather than as a documented intention.
5. Record the hosting region in the README, because I have probably already
promised it to an ethics committee in writing.
6. Public form endpoint: rate-limit it, keep uploads off the application server,
cap size and type, and assume it is scanned the day the URL hits a poster.
7. Patching is mine now. Subscribe me to the project's security announcements,
write down the upgrade procedure, and upgrade a copy with a real response set
before touching production mid-fieldwork.
8. Add external monitoring on the public survey URL before fieldwork opens.
Nothing inside the instance can tell me the instance is down, and downtime
during a recruitment window is data I never get.
9. If I insisted on my own engine: persist partial responses without a login,
make submission idempotent, and build the export before the editor.
10. Out of scope, and say so instead of half-building it: quotas, randomisation
blocks, expression-based branching, panels and multilingual surveys. Needing
those is the moment €26 a month becomes the cheap option.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 first time a consent form uses the word anonymous, or the first time an ethics submission names a country. Twenty-six euros a month rents a European processor, a choice of hosting region, an upgrade window that is not yours, and someone else's obligation to keep an internet-facing PHP application patched while your fieldwork is open. That is not a hosting bill; it is most of the compliance answer, and it costs less than the afternoon you would spend writing the data-processing section yourself.
$26/mo is cheaper than your weekend.
Surveys export as LSS/LSA structure files and responses export as CSV or SPSS, which makes moving between a self-hosted instance and Cloud genuinely tractable — that is the strongest argument for running the real project rather than your own thing. Export both halves on a schedule, not on the day you need them, and keep the structure files in git so a survey definition can be rebuilt from scratch. The parts that do not export are the ones to write down by hand: the hosting region you promised, the retention clock you started, and which surveys carried an anonymity guarantee. Nobody has that list until an auditor asks for it.
The product itself: GPL, self-hostable, with quotas, expression-based branching, token management and dozens of question types already built.
Open-source survey and experience platform with a modern stack and a straightforward self-hosting path.
Open-source conversational form builder with a collection backend, lighter than LimeSurvey and easier to operate.
Questions
It's open source. Why is self-hosting rated this harshly?
Because the verdict is about consequences, not authorship. Running the real engine removes almost all of the code risk, which is exactly why this entry tells you to do that rather than build one. What is left is custodial: you are now the named processor for free-text answers written by people who were promised anonymity, on a public PHP endpoint whose CVEs are your problem. Excellent code does not change any of that.
What actually breaks the anonymity promise?
The default schema, plus time. Invitation tokens and responses sitting in one database is convenient and normal, and it means the join that de-anonymises the survey is two lines that any analyst could write without knowing they had done something wrong. Separate them at the storage level before fieldwork and the promise on your consent page becomes something the system enforces rather than something you intend.
Could I just build a simple form and skip all this?
For a lunch poll, yes, and that is the SHIP IT case at the top of the page. The gap opens at the features people do not think of as features: partial-response persistence without a login, quotas that close a segment mid-fieldwork, randomisation blocks, piping, and an export a statistician will accept. Those are the reason survey software exists, and they are also the reason your weekend version stays a weekend version.
How is this different from the Activepieces Cloud and Appsmith Cloud entries?
Same shape, different hazard. Those two are about operations — queues, credentials, upgrade windows. This one is about custody: the thing you are hosting is other people's disclosures, collected under a promise, on a fixed schedule that cannot be re-run. The backup you never tested matters more here because the data is not reproducible at any price.
- 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.
NPS is not measured, it is manufactured — by who you emailed, when, and whether you chased the quiet ones.
“Responses are anonymous” is an engineering claim. Your access log, invite token and timestamps disagree.
Activepieces is MIT, so don’t build it — run it. Then answer the real question: who gets paged at 4am?
last reviewed 2026-08-05 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice