Should I vibe code
Hosted forms, surveys, payments, reports, and secure workflows
The approval link in that email is a password. Yours is the row id, and the row is somebody's HR file.
?
Their verdict, the Professional price and the build-time estimate come from their entry, MIT-licensed. Checked 2026-08-05.
?
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
The other form builders here are consumer products that happen to end up holding personal data. Formsite is an institutional one and has been for twenty years, and you can read that straight off the pricing table: sub-user accounts with restricted permissions, unlimited workflows, and merged PDF and Word documents generated from results. Those three features describe an HR department, a university registrar and a claims desk. A workflow is a form that routes — the applicant completes part one, a manager approves part two, someone in HR finalises part three — and every hop is a link emailed to a person. That link is a bearer credential for a record containing a stranger's ID scan, salary expectation and bank details, and an agent will build it as a URL with the submission id in it, because that is what works when the only person testing is you. Fillout's entry is about not knowing what you collected. This one is about knowing exactly what you collected and then mailing out the key.
What actually breaks
not "if". the specific failures.
- The workflow link, which is an emailed bearer token for a record you did not write an authorisation check for — and email is forwarded, quoted, auto-archived and sent to the wrong Dave roughly once a quarter
- Sub-users, because 'restricted permissions' is a whole authorisation model and what gets generated is a boolean called isAdmin
- Partial saves. Save-and-return is Formsite's headline feature and it means half-finished submissions containing half of somebody's medical history sit in your database under a resume link with no expiry
- File uploads, arriving as arbitrary bytes from strangers, in a category of form where the attachment is a passport scan, a payslip or a P45
- Document generation, which is a template engine reached by untrusted input — a merge field that renders user-supplied markup into a PDF is an injection surface with an official-looking letterhead
- Payment integrations, the moment somebody adds a fee field to a registration form and your build acquires a money path nobody designed
- Retention, which institutions have written policies about and your schema has no opinion on: an application form kept for six years is a legal obligation in one jurisdiction and a violation in another
- The results export, a CSV of everything, downloaded to a laptop, emailed to a colleague, and now living in three places your deletion routine has never heard of
The recruitment workflow has been running since spring and everybody likes it. Applicant fills the form, the hiring manager gets a link, one click and they are looking at the application with an Approve button underneath. On a Thursday a manager forwards one of those emails to a candidate by mistake — not the record, just the mail, with the line 'does this look right to you?' The candidate clicks, because why would they not, and finds themselves inside the review view for a different applicant: name, address, current salary, the scan of a driving licence, and two lines of manager commentary that were never meant to leave the company. The link had no session behind it. It never had one. It was a URL with a submission id, and the id one along from it is another human being. What makes the following week genuinely bad is not the disclosure — it is that you cannot bound it, because every one of those links ever sent still works, none of them expired, and you have no log of which ones were opened by whom.
Is that you?
the verdict is a default, not a law
- It is one form, it collects a name and an email, and there is no second step
- Every read of a submission requires a real session belonging to a real account, and you have written the test where user B asks for user A's record and gets a 404
- Nothing is ever emailed except a notification that a submission exists — no content, no link that works without logging in
- There are no uploads, no payments and no generated documents, and adding any of them means revisiting this decision
- Any step of a multi-form workflow is reachable from a link that does not require authentication
- It is being used for recruitment, admissions, benefits, claims or intake — categories where the attachment is an identity document by default
- You cannot say, today, how long a submission is kept and which job deletes it
- The forms are built by people other than you, because your database's contents are now whatever a colleague thought of on a Tuesday
- There is a fee field anywhere in it and the amount is calculated in the browser
If you build it anyway
the checklist, then the prompt that enforces it
- There is no such thing as an approval link. Every step of a workflow requires an authenticated session; the email says 'you have something to review' and nothing more.
- If a magic link is genuinely unavoidable, make it single-use, short-expiry, bound to one recipient address and one record, revocable in bulk, and logged on open. Then write down that you did all five, because the version that ships usually has one.
- Build the permissions model before the form builder. Sub-users mean a matrix of who may see which form's results, and it needs a test per cell, not a boolean.
- Give partial submissions an expiry and a purge job, and treat a resume link exactly as strictly as an approval link.
- Uploads are off unless requested, stored under random keys, never served from a path the uploader influenced, scanned, size-capped and type-checked by content rather than by filename.
- Document merge runs in a sandbox with untrusted input escaped by default. A generated PDF is not a safe output format; it is a renderer with a parser attached.
- Amounts are computed and validated server-side against a price list the submitter cannot see, and payment goes to a hosted checkout you never handle card details for.
- Set retention per form before the form can be published, enforce it with a scheduled job, and prove the job deletes the uploads and the generated documents, not just the row.
I am building a hosted form platform with multi-step workflows: someone
submits, someone else reviews, someone else approves. The records will hold
identity documents and salary data. Build the authorisation model before the
form builder.
1. Tell me first that a workflow step reachable from an emailed URL is an
unauthenticated read of somebody’s HR file.
2. Every review and approval screen requires a real session. The
notification email carries no record content and no link that works
logged out.
3. If I insist on a magic link: single-use, expiring within the hour, bound
to one address and one record, revocable in bulk, logged on open.
4. Authorisation before display: scope every read by form ownership and
step, and write the test where user B asks for user A’s submission and
gets a 404.
5. Retention next. No form publishes without a retention period and a job
that enforces it, deleting the row, the uploads and the generated PDFs.
6. Then deletion on request: one command that erases a respondent
everywhere, exports and merged documents included.
7. Only then the public endpoint — rate limited, challenged, payload capped,
unknown fields rejected rather than stored.
8. Partial saves get the same expiry and link rules as approvals. A
half-finished form is a half-finished disclosure.
9. Uploads off by default. If enabled: random object keys, content-sniffed
types, size caps, never a path the uploader chose.
10. Document merge runs sandboxed with user input escaped. A merge field
must not render markup into a PDF.
11. No card numbers: validate amounts server-side and send checkout
somewhere hosted. Finish by telling me what Formsite Professional costs
monthly.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
As soon as a second person has to touch a submission. Forty dollars a month buys twenty years of somebody else answering the questions you are about to answer badly: how a review link is scoped, what a restricted sub-user can see, how long a partial response lives, what happens to the merged PDF when the record is deleted. Formsite publishes AES-256 encryption at rest, a data-retention control and PCI attestation, and it sells a HIPAA arrangement at the top tier precisely because clinics turn up. Building the form is the cheap half. Being the custodian of an identity document a stranger uploaded because your page asked for it is the half with statutory deadlines attached.
$39.95/mo is cheaper than your weekend.
Export submissions as JSON alongside the form definitions that produced them, because a results table without its schema is unreadable inside a year and Formsite's own export is worth matching. Uploaded files come out as a bucket you can hand over wholesale, with a manifest mapping object keys to submissions. The part nobody plans for is the workflow state: which record is at which step, who approved what and when. That is an audit trail somebody may have to produce, so export it as an append-only log rather than a status column. Then, before anything is switched off, run the retention job to completion and invalidate every outstanding link — an abandoned form backend is a live disclosure surface with nobody watching it.
Open-source survey and experience platform, self-hostable so the submissions stay on infrastructure you control.
Open-source form builder and collection backend with a self-hosted deployment path.
Questions
There are five form builders on this site. What is actually different about this one?
The routing. Typeform's entry is about the respondent experience, Fillout's is about not controlling what your own form asks for, Cognito Forms' and Paperform's are about a total computed in the browser. Formsite's distinguishing feature is that a submission travels: it is created by one person and then read, annotated and approved by others. That turns the product from a data-collection problem into an authorisation problem, and authorisation is the thing generated code is most confidently wrong about.
Everyone sends approval links by email. Why single it out?
Because everyone who does it properly puts a session behind it, and the version an agent writes does not. The generated pattern is a URL containing the record id, because that is the version you can test alone at 11pm. Nothing about it looks wrong in review. It only becomes visible the first time somebody forwards the mail, and by then every link you have ever sent is still live, because expiry was not in the requirements either.
Does the HIPAA question apply to me if I am not a clinic?
Probably not directly, and that is exactly the trap. Formsite sells HIPAA arrangements at the top tier because a certain kind of customer needs them; what reaches you is the same shape of data without the paperwork. A university's accommodations form, an employer's leave request, a charity's intake sheet — all of these collect health information from people who have no idea who wrote the software. You will not be prosecuted under HIPAA. You will simply be holding the data it exists to protect, with none of the controls it would have required.
- GDPR Art. 5 — principles relating to processing of personal data (EU)
- GDPR Art. 32 — security of processing (EU)
- 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.
You never decided to store health data. A dropdown someone added to an event signup decided it for you.
If the total is computed in the browser, your order form has a price field. Someone will find it before you do.
A total computed in the browser is a discount code for anyone who can open devtools.
last reviewed 2026-08-05 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice