Should I vibe code
Polished one-question-at-a-time forms, surveys, quizzes, and lead capture
One question at a time means storing answers from people who thought about it and decided not to submit.
?
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
What separates Typeform from the other form builders here is not what it collects but how: one question at a time, which turns a form from a page into a session. Two things follow that a weekend build gets wrong. A session has state, so a respondent who refreshes on question nine either resumes or starts over, and the generated version never resumes — the answers only ever lived in browser memory. And answers arrive before anybody presses submit, so the obvious implementation saves question four the moment it is answered, which means your table now holds responses from people who read the question, thought about it, and decided not to give it to you. That is a harder position to explain than a plain form's all-or-nothing. Underneath sits the ordinary form problem: a public POST endpoint, spam within days, retention nobody set. What keeps this at demo-only rather than a build is that Typeform's actual product is measured in completion rate, and completion rate is made of transition timing, mobile keyboard behaviour and the exact moment the next question appears. You will not tune that in a weekend, and with no traffic you will not be able to tell whether you have.
What actually breaks
not "if". the specific failures.
- A refresh on question nine, which restarts a fourteen-question form because the answers only ever lived in browser memory
- Partial responses, which either do not exist — and you never learn where people quit — or do exist, and you are holding data nobody chose to send
- Logic jumps, where a branch that skips a required question is invisible in testing because you only ever walk your own path through the form
- The browser back button, which on a one-question-at-a-time flow is the button people actually press, and which by default leaves the page entirely
- Mobile keyboards, which cover the button, resize the viewport mid-transition, and are most of the reason the polished version costs money
- Hidden fields passed in the query string, so a respondent's email travels in a URL that lands in referrer headers, analytics and pasted links
- The public submission endpoint, which gets indexed and then spammed, at whatever rate the spammer prefers
- Retention, which nobody sets, so three years of survey answers accumulate in a table with no deletion path and no owner
Is that you?
the verdict is a default, not a law
- The form is short, internal, and the audience is a room you could walk into
- Answers are written only when the respondent submits, so an abandoned session leaves nothing behind
- You are not optimising completion rate, because that is the part you would actually be buying
- The conversational presentation is a preference rather than a requirement, and a plain page of questions would do
- You store per-question answers as they are typed and have not decided what an abandoned session means
- The form branches and nobody has walked every path through the logic
- It asks anything a respondent would reasonably expect to be able to withdraw, and there is no deletion path
- It is public with no rate limit, no honeypot and no bot check in front of the endpoint
- The responses will inform a decision, because a form with a 22% completion rate surveys the patient, not the population
If you build it anyway
the checklist, then the prompt that enforces it
- Decide what a partial response is before you write the storage. If you record per-question, say so on the first screen and give partials a shorter retention than completed responses.
- Keep session state server-side behind a resume token, so a refresh at question nine does not throw away eight answers.
- Treat the logic map as code: enumerate every reachable path in a test and assert that none of them requires a question the respondent was never shown.
- Validate on the server against the stored question definitions, not against what the client claimed the question was.
- Pass identity as an opaque token resolved server-side. Hidden fields in the query string put respondent identity into every referrer header the page emits.
- Rate limit per IP and per form, add a honeypot and a minimum time-to-answer, and leave a seam where a real bot check goes.
- Give every completed response a reference and email the respondent a copy. That receipt is how they tell you when your side lost it.
- Test on a real phone. The conversational format either survives the mobile keyboard or it does not, and a resized desktop window will not tell you which.
I am building a conversational form — one question at a time, advancing as
each answer is given, filled in by strangers. Build it so a half-finished form
is a deliberate decision rather than an accident, and push back on shortcuts.
1. Before any storage, ask me what a partial response is. If I want
per-question saves, say plainly that I am then holding answers from people
who chose not to submit, and make me set a shorter retention for them.
2. Session state lives server-side behind an opaque resume token, not in a
React state object. Make refresh-on-question-nine work before anything else.
3. The question set is a server-side definition. Validate every answer against
it on the server; never trust the client about what was asked or required.
4. Branching logic is code, so test it like code: enumerate every reachable
path, assert none requires a question the respondent never saw, none loops.
5. Identity from hidden fields goes in an opaque token resolved server-side,
never in the query string, where it lands in referrer headers and analytics.
6. Spam defence before launch: rate limit per IP and per form, a honeypot, a
minimum time-to-answer, and a seam where a real bot check plugs in.
7. Every completed response gets a reference and the respondent gets an emailed
copy. That receipt is how they tell me when my side lost it.
8. Write one deletion operation that removes a respondent's session, answers,
partials and exported copies together, and prove it with a test.
9. Out of scope unless I ask: payments, uploads, and anything that quotes a
price. If I ask for a total on the form, re-derive it server-side.
10. Finish by telling me that completion rate is what the paid product actually
sells, and that I cannot tune it without traffic I do not have.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 form is public and the answers will be read by more than you. $28 a month buys the response pipeline — spam filtering, partial handling, deletion, the receipt email — plus the completion-rate work, which is the only genuinely expensive part of this product and the only part you cannot replicate without traffic. Build your own for internal forms and anything where a lost submission costs a Slack message.
$28/mo is cheaper than your weekend.
Keep the question definitions as JSON in version control rather than as rows in a builder table, and export responses on a schedule as newline-delimited JSON with the question IDs intact — not as a flattened CSV whose columns shift the moment somebody edits a question. Keep partials in their own table, so abandoning the project does not mean inheriting a pile of data you cannot describe. The part that does not migrate is the form URL: keep the paths stable and be ready to redirect them at whatever replaces you.
Open-source form builder with surveys and forms; useful prior art for Typeform-like flows.
Self-hostable conversational form and chatbot builder — the closest open implementation of the one-question-at-a-time flow, branching logic and resumable sessions included.
Questions
Why is this only DEMO ONLY when Paperform and Fillout are YOUR FUNERAL?
Because of what the forms end up doing. Paperform's compute a total on your own domain, which is a published quote somebody expects you to honour. Fillout's problem is that a colleague can start collecting health data through the builder without anybody deciding to. Typeform is mostly surveys and lead capture — the same custodial duty, one notch lower stakes. What is specific here is the session model: partial answers, resumable state, and a product whose value is a completion-rate number you cannot measure at home.
Should I save answers as they are given, or only on submit?
Only on submit, unless you can say out loud why you need the partials and when you delete them. Saving as you go is genuinely useful — it is how you find the question where everyone quits — but it means a respondent who reads question six, decides it is too personal and closes the tab has still given you questions one through five. If you do it, say so on the first screen and expire partials fast.
What is the smallest version worth building?
One form defined in a JSON file, rendered a question at a time, writing a complete response to one table on submit, with a honeypot and a rate limit. That is an evening and it covers every internal use. Resumable sessions, branching logic and partial-response analytics are the three things that turn it into a project, in roughly that order.
- GDPR Art. 5 — principles relating to processing of personal data (EU)
- GDPR Art. 6 — lawfulness 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.
Jotform will sign a BAA. You will not. That one sentence is the whole verdict.
A total computed in the browser is a discount code for anyone who can open devtools.
You never decided to store health data. A dropdown someone added to an event signup decided it for you.
last reviewed 2026-08-04 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice