Should I vibe code
Form builder with payments, approvals, apps, tables, and workflow tools
Jotform will sign a BAA. You will not. That one sentence is the whole verdict.
?
Their verdict, the Bronze 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
Every other form builder on this site is rated on what its forms might collect. Jotform is rated on what it sells on purpose. Two of its headline features are a payment field that charges a real card inside the form, and a Gold tier where the company signs a business associate agreement so clinics can run patient intake through it. Rebuild those and you have quietly taken on the two categories this site reserves the red verdict for: other people's money and health data. The payment half is the one people underestimate — the moment your own page renders a card input rather than handing off to a hosted field, you are in PCI scope, and the amount that gets charged is whatever your form posted, which on a generated build is a number the browser computed. The HIPAA half is not even a technical problem. A covered entity that routes intake through your software makes you a business associate, and a business associate without a signed BAA and the safeguards behind it is not a gap you close later, it is a contract your customer cannot legally be in. Jotform charges $129 a month for the tier where they sign that paper. The paper is the product.
What actually breaks
not "if". the specific failures.
- The payment amount, because a generated checkout takes the total from the request. A form that prices itself from its own answers will happily accept a total of 1, and you find out at reconciliation rather than at checkout
- PCI scope, the instant a card field renders on your own page instead of inside a hosted field or a redirect — that single choice moves you from the shortest self-assessment questionnaire to the long one, over a side project
- The business associate gap, which is not a bug you fix in a sprint: a clinic using your intake form needs a signed agreement and the safeguards behind it before the first submission, not after
- Uploads, which on a form product means insurance cards, driving licences, prescriptions and x-rays landing in a bucket whose object keys were never designed to be unguessable
- The submission PDF and the notification email, which take a copy of everything the form collected and put it in an inbox with different retention, different access and no audit trail
- The builder itself, once a colleague can create forms. You are no longer the person who decides which fields exist, and the field that ends this entry gets added by someone in marketing on a Thursday
- Approval links, the pattern where an email contains a one-click approve URL that acts without a session — a forwarded thread becomes an authorisation
- Deletion, which has to reach the submission row, the generated PDF, the notification email, the uploaded files, the tables view, any integration you pushed to, and the backups
- The public endpoint, which bots find within days and fill with junk, and which has no rate limit because nobody rate-limits their own contact form
The message that starts it is not from an attacker. It is a practice manager at one of your customers, forwarding a Google result. Your "download a PDF copy of this submission" route takes the submission ID in the query string and checks nothing else, and about eight months ago somebody pasted one of those links into a public support thread. A crawler found it and walked the neighbouring IDs. What is now indexed is a run of new-patient intake forms: names, dates of birth, insurance member numbers, and the free-text box where people describe, in their own words, what is wrong with them. The clinic's obligation from this point is a breach notification with a count and a date range on it. Yours is to explain that you can supply neither, because the PDF route was the one endpoint you wrote before you added request logging, so you cannot say how many were fetched, by whom, or starting when.
Is that you?
the verdict is a default, not a law
- The form collects a name, an email address and free text, and you are the only person who can add a field to it
- No money moves — no card field, no payment link, no total computed anywhere
- Nothing is uploaded, which removes an entire class of failure in a single decision
- No healthcare provider, insurer, school or law firm is on the list of people who might use it
- Every submission gets a retention deadline at write time and a job that actually enforces it
- There is a payment field of any kind, including one that only sometimes charges
- A covered entity — clinic, dental practice, therapist, insurer — is one of your users, because you have become their business associate whether or not anybody said the word
- Anyone other than you can create a form, since you have then delegated the decision about what data you hold
- Respondents upload documents or photographs
- You cannot answer, for the last ninety days, which submission was viewed or downloaded and by whom
If you build it anyway
the checklist, then the prompt that enforces it
- Decide first whether money touches this. If it does, stop building and use a hosted checkout: Stripe Checkout, a Payment Element, or a redirect. Nothing on your page should ever see a card number, because that decision alone determines which PCI questionnaire you are answering.
- The charge amount is derived on the server from a price list you control, never accepted from the request. A total posted by the browser is a discount field with extra steps.
- Refuse healthcare intake outright unless you can sign a BAA and mean it. There is no partially compliant version, and the safeguards it obliges are considerably more than encryption at rest.
- Build deletion before submission. Enumerate every destination a submission reaches — row, PDF, notification email, uploaded files, downstream integration, backup — and make erasure one operation across that list, then test it by searching for the value afterwards.
- Authorise every read. A submission ID in a URL is not an access control, and PDF and export routes are where that is always forgotten.
- Log every view, download and export with user, submission ID and timestamp. After an incident this is the difference between a report and a shrug.
- Do not email the submission contents. Email a link that requires a login, so the data has exactly one home with exactly one retention policy.
- Uploads go to private storage with random keys, short-lived presigned URLs, a content-type allowlist and a size cap — and never to a path that can be enumerated.
- Rate-limit and bot-check the public endpoint on day one, because it is a write endpoint that strangers can reach and it will be found.
I am building a form product: forms other people fill in, with notifications, file
uploads and an admin view. Follow this order and push back where I ask for the
things below.
1. Before any code, ask me two questions: does this form take money, and will a
healthcare provider ever use it? If either answer is yes, say plainly that a
vendor who signs a BAA and keeps card data off my page is the cheaper and
safer answer, and make me confirm before continuing.
2. If money is involved, use a hosted checkout — Stripe Checkout, Payment
Element or a redirect. Never render a card input on my own page. If I ask you
to, refuse and explain what it does to my PCI scope.
3. The charge amount is computed server-side from a price list in my code. Never
accept an amount, a discount or a line-item total from the request body.
4. Build deletion before submission. Enumerate every place a submission lands —
database row, generated PDF, notification email, uploaded files, downstream
integrations, backups — and implement erasure as one operation over all of
them. Prove it with a test that searches for the value afterwards.
5. Then authorisation. Every route that returns a submission — view, PDF,
export, print — checks the session and the owner. A submission ID in a URL is
not an access control. Write the negative test first: request another
account's submission by ID and assert an empty body.
6. Then logging: record every view, download and export with user, submission ID
and timestamp before launch, and keep field values out of application logs by
allowlisting the fields that may ever be logged.
7. Notification emails carry a link that requires a login, never the submission
contents. One copy, one retention policy.
8. Uploads only if I insist: private storage, random keys, presigned URLs that
expire in minutes, content-type allowlist, size cap, no enumerable paths.
9. Every submission gets a retention deadline at write time, enforced by a job.
10. Rate-limit and bot-check the public submit endpoint in v1, not later.
11. Out of scope until I ask: approval-by-email links that act without a session,
letting other users build their own forms, and any medical field at all.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 does anything beyond collecting a name and a message. $39 for Bronze buys the submission plumbing, but the tier that matters here is Gold at $129, and what that price covers is the signature on a business associate agreement, the audit trail, the retention controls and a company that answers your customer's security questionnaire instead of you. You can write a form. You cannot write yourself a BAA, and no amount of good code substitutes for one.
$39/mo is cheaper than your weekend.
Forms are portable and submissions are not. Export the form definitions as JSON — every builder can re-import that shape in an afternoon — and the submissions as CSV with the uploaded files alongside, keyed identically. Then treat that export as the most dangerous object the project ever produced, because it is one archive containing everything this page spent its length worrying about: encrypt it, give it an expiry, keep it off laptops. If payments were involved the exit is longer than the export, since charges, refunds and disputes live at the processor: reconcile before you switch anything off, and keep the mapping between your submission IDs and the payment intents for as long as chargebacks can still arrive. The honest last step is deleting your copy and being able to show that you did.
Actively developed open-source survey and experience platform, self-hostable so submissions stay on infrastructure you control.
Open-source form and API platform with JSON-defined forms, conditional logic and server-side validation as a first-class idea.
Open-source Typeform alternative, archived by its maintainers in 2024 and no longer receiving fixes.
Questions
Isn't ABSOLUTELY NOT harsh for a contact form?
It would be, and a contact form is not what Jotform sells. The verdict is scoped to the product being replaced: forms that charge cards, and forms that carry patient intake under a signed BAA. Strip both out and you are left with something closer to our Typeform entry, which is DEMO ONLY. The shipItIf list on this page is that version, written down.
I'm using Stripe, so payments are handled. Doesn't that solve it?
It solves the part everyone worries about and not the part that actually bites. Stripe Checkout or a Payment Element does keep card numbers off your servers and your PCI scope small — that is the right call and you should make it. What it does not do is decide the amount. If your form computes a total from its own answers and the browser posts that total, Stripe will charge exactly what you asked it to, correctly, every time, including the time somebody edited the number.
What actually makes me a business associate?
Handling protected health information on behalf of a covered entity does. It is a role you fall into by processing the data, not one you opt into by ticking a box, and the rules require a written contract before the relationship starts. That is why every vendor in this space gates HIPAA behind a specific paid tier: the tier is where the signature and the obligations live.
How is this worse than Fillout or Feathery, which store identity documents?
Those entries are about data arriving that nobody planned for — a medical question added to an event signup, an ID scan uploaded to an application. That is bad, and it is your-funeral bad. Jotform differs in kind because both hazards are deliberate features with a price attached: a payment field and a compliance tier. You are not sleepwalking into money and health data, you are choosing to rebuild the parts of a product that exist specifically to carry them.
- 45 CFR Part 164 — HIPAA Security and Privacy Rules (US)
- 45 CFR 164.308 — administrative safeguards, including business associate contracts (US)
- PCI DSS standards library
- Stripe — reducing your PCI scope
- 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.
You never decided to store health data. A dropdown someone added to an event signup decided it for you.
A total computed in the browser is a discount code for anyone who can open devtools.
One question at a time means storing answers from people who thought about it and decided not to submit.
last reviewed 2026-08-05 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice