Should I vibe code
Forms with calculations, payments, workflows, and document generation
If the total is computed in the browser, your order form has a price field. Someone will find it before you do.
?
Their verdict, the Pro 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
A form builder is the most deceptive weekend project on this site, because the demo is real. Drag fields, save a schema, render inputs, write rows — an agent does that in an evening and it works. Then look at what Cognito Forms is sold for. Calculations that decide how much to charge. A payment step. Conditional logic that hides and shows fields. Document generation that merges submissions into PDFs. And an Enterprise tier that exists almost entirely to attach a HIPAA business associate agreement, encryption at rest and a one-hour session timeout to the same product, because clinics build patient intake on it. Every one of those is a way for a public, unauthenticated write endpoint to become something worse: a price field an attacker controls, an uploads bucket with guessable keys, a submissions table holding a stranger's medical history in a column you named notes. The build is easy and the failure lands on people who filled in your form and never met your code. That is the definition of this band.
What actually breaks
not "if". the specific failures.
- The amount. If the total is calculated in JavaScript and posted with the submission, the price is an input, and a $400 registration becomes $4.00 with one edit in devtools
- Conditional logic, on the server side, where it usually does not exist — hidden fields are hidden in the browser and wide open in the POST body
- File uploads, which arrive as arbitrary bytes from strangers and end up in a bucket whose object keys are the submission id plus one
- The free-text box, the first time somebody writes a diagnosis, a medication or a bank account number into the field you labelled "anything else?"
- The submissions table, which is a growing pile of other people's personal data with no retention policy and no delete path, because neither was interesting to build
- Spam, within days of the URL becoming public — an open POST endpoint with an email field is a mail-relay probe waiting to happen
- Notification email, which cheerfully quotes the whole submission into a message and scatters copies of the sensitive fields across inboxes and mail logs
- Document generation, which is a template engine reached by untrusted input, and a PDF merge that renders user-supplied markup is an injection surface
The discrepancy surfaces during month-end reconciliation, which is why it took six weeks. The conference registration form had three ticket types and an early-bird calculation, and the total was worked out in the browser and sent along with everything else. Someone noticed. They did not do anything clever — they changed a number in a request and submitted, and the payment intent was created for the amount your server was handed. It worked, so they told a forum, and by the time anyone looked at the numbers there were nineteen full-price attendees who had paid between one and six dollars, all with valid confirmation emails and valid tickets and valid names on the door list. The refunds are not the problem; there is nothing to refund. The problem is that the organiser now has to decide whether to turn away nineteen people holding confirmations your system sent them, and every one of those conversations happens at a registration desk, in person, in front of a queue.
Is that you?
the verdict is a default, not a law
- It is an internal form for colleagues, behind your existing login, with no payment step
- The fields are name, email and a message, and you would be comfortable reading every submission aloud
- Money is handled by a hosted Stripe or Paddle checkout that owns both the price and the card, and your form only records that it happened
- You self-host Formbricks or HeyForm and add the two fields you need, instead of writing a form engine
- The form charges money and your code decides the amount
- A clinic, therapist, school or law firm will put it in front of their clients, which makes you their processor and their breach your problem
- It accepts file uploads and nobody has decided what happens to a 2GB file, an SVG with script in it, or a filename containing path separators
- There is no answer to "how does someone ask you to delete their submission", because that question is coming
If you build it anyway
the checklist, then the prompt that enforces it
- Prices live on the server, keyed by product, and the client sends an item identifier and a quantity — never an amount. This one rule removes the most common way a form built in an evening loses real money.
- Re-evaluate all conditional logic on the server. Fields hidden by the browser are not hidden from a POST, so validate the submission against the schema as though the form UI never existed.
- Use hosted checkout so no card number touches your infrastructure. A custom card field takes a side project out of the smallest PCI scope there is and into the standard proper.
- Decide up front whether anything a respondent types could be health, financial or legal information. If yes, that is a different architecture — separate encrypted store, its own retention clock, its own access log — and it is a decision, not a setting.
- Never render a full submission into a notification email. Send "you have a new response" plus an authenticated link, so the sensitive copy lives in one place instead of eight inboxes.
- Treat uploads as hostile: size caps, an extension and content-type allowlist, generated random object keys, storage outside the web root, and served only through a signed, expiring URL.
- Write the export and the delete path before the form renders a single field. A form product without both is a personal-data landfill with a nice UI.
- Put a rate limit and a bot check on the public endpoint the day it goes live, not the day after the spam starts.
I am building a form builder that collects submissions, runs calculations and takes payments. Work in this order and argue with me when I try to skip ahead.
1. Before any UI, ask me what the most sensitive thing anyone could type into one of these
forms is. If the answer involves health, money or a licensed profession, say plainly
that this changes the storage design and that I should consider buying instead.
2. Server-side pricing is not negotiable. The client posts an item id and a quantity; the
server looks up the price and computes the total. If I ask you to accept an amount from
the browser, refuse and explain the devtools attack in one sentence.
3. Re-validate every submission against the schema on the server, including fields the
conditional logic hid. Hidden in the browser is not absent from the request.
4. Write the delete path and the export path before the form renders. One call must remove
the submission row, uploaded files, generated documents, queued notifications and the
payment-processor customer record. Enumerate them and write the test.
5. Never put submission contents in a notification email or a webhook body. Send a link
that requires authentication.
6. Uploads are hostile input: cap the size, allowlist content types, generate random object
keys, store outside any web-served path, and serve only through short-lived signed URLs.
Reject SVG unless I explicitly ask for it and accept the script-injection consequence.
7. Payments go through hosted checkout. Do not build a card input. Do not log the payment
payload. Make the create-payment call idempotent on submission id.
8. Rate-limit the public submit endpoint per IP and per email, add a bot check, and cap
payload size, all before the URL is shareable.
9. Give every form a retention period at creation time, default it to something short, and
write the job that actually enforces it. A form with unlimited retention is a growing
liability with no owner.
10. Store submissions encrypted at rest in their own table, behind one accessor, with an
access log. Do not scatter answers across a JSON blob next to operational data.
11. Deliberately out of scope unless I ask again: document generation and PDF merge,
e-signatures, multi-step approval workflows, and anything described as HIPAA-ready.
Each of those is its own product with its own legal surface.
12. Finish by listing what you skipped, and tell me that a vendor charges about $24 a month
to have answered all of this, and considerably more to sign a BAA about it.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
Money changes hands, or the form goes in front of anyone's clients but your own. Twenty-four dollars a month is roughly one tampered registration, and what it buys is a company that has already decided how conditional logic is enforced, where uploads go, how long responses live and who signs what. If a licensed practice is involved, the honest answer is not "buy the $24 plan" but "buy the tier that comes with a business associate agreement", and that price difference is the clearest signal on their pricing page about what you would be taking on.
$24/mo is cheaper than your weekend.
Make the form definitions and the submissions both exportable from day one: schema as JSON, responses as CSV plus a manifest of uploaded files, generated on demand rather than promised. Keep payments in the processor with a submission id in the metadata, so the financial record survives your database. The genuinely awkward part of leaving is the live URLs — a form embedded on somebody's site or printed on a flyer keeps receiving traffic long after you stop caring, so decide now that every form has an end date and a redirect, and that shutting the project down means turning forms off rather than turning a server off.
Open-source survey and form platform, self-hostable, with the response storage and delete paths already thought through.
Open-source conversational form builder with a collection backend, logic and integrations.
Questions
canivibecodeit says yes, one sitting. Why the harsher call?
Because they are answering whether an agent can build it, and it can — that part is not in dispute, and it is exactly what makes this dangerous. A form engine with conditional logic and a payment step is genuinely an evening's work, and every shortcut in that evening lands on a stranger who filled in the form. We are not disagreeing about difficulty; we are disagreeing about who is holding the consequences.
Does HIPAA really come into a form builder?
It comes into the practice using it, and then into anyone processing that information on the practice's behalf. Cognito Forms restricts HIPAA compliance to its Enterprise tier and requires a signed business associate agreement precisely because patient intake is one of the things people build on it. If a clinic puts your form in front of patients, the software holding those answers is in scope, and outside the US the same answers are special-category data under GDPR Article 9. Neither question can be answered by your schema.
What is the version of this I can actually ship?
An internal form behind your existing authentication, with no payment step and no uploads, writing to a table you already back up. That is a good evening and it is genuinely competitive with a paid product. The moment the URL goes public, or an amount is calculated, or a file is attached, you have crossed into the version this page is about.
- 45 CFR Part 164 — HIPAA Security and Privacy Rules (US, eCFR)
- GDPR Art. 5 — principles relating to processing of personal data
- GDPR Art. 32 — security of processing
- PCI DSS standards library
- Stripe — reducing your PCI scope
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.
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