Should I vibe code
Build a multi-step application form with validation and reusable field groups
The multi-step form is an hour. Storing somebody's SSN, ID scan and bank statements is not an hour, ever.
?
Their verdict, the Growth (custom quote) 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
The form is the easy half and it is not the half that matters. An agent will produce a good multi-step form in an hour — conditional branching, field groups, save-and-resume, a progress bar, all of it. Then look at what Feathery is now selling: intake for wealth managers, broker-dealers, insurance carriers and MGAs, with document extraction, e-signature and SOC 2 Type II and HIPAA attestations on the page. That is an onboarding form carrying a date of birth, a Social Security number, a photograph of a driving licence, twelve months of bank statements and, on an insurance application, a list of medical conditions. Your build inherits all of that on day one and none of the machinery for holding it: field-level encryption, an upload pipeline that does not put an ID document in a public bucket, a retention clock, an audit trail, and logs that do not contain the SSN somebody typed into a field labelled 'other'. The build is a sitting. The consequences last as long as the data does.
What actually breaks
not "if". the specific failures.
- The uploads bucket, which is where the driving licences and bank statements land and where a predictable object key or a stray public-read policy turns into a disclosure notice
- Your logs, which will contain the field values — an application form logs its request bodies exactly once before anybody thinks about it, and then the SSN is in a log aggregator with a different retention policy and a wider audience
- Save-and-resume, which is a link emailed to an applicant that reopens a half-finished form containing their financial details, and which almost always ends up as a long-lived, guessable, never-expiring token
- Partial submissions, because a form that saves as you type stores the data of everyone who abandoned it, including people who changed their mind about applying
- Validation drift, where the front end enforces the rules and the API does not, so anything can be posted to the endpoint the embed is talking to
- The e-signature, which is a legal artefact and needs an audit trail — signer identity, IP, timestamp, the exact document bytes hashed — or it is a picture of a name
- Document extraction, which is confidently wrong on a smudged scan and writes the wrong account number into a workflow that nobody re-reads
- Deletion, which has to reach the submission row, the uploaded files, the extracted fields, the CRM record you pushed, the email that carried a PDF copy, and the backups
A broker emails at nine on a Friday because a client called: the client's application PDF opened for someone else. Your resume links are the submission id signed with a static secret, and eight weeks ago you changed the signing payload without rotating the secret, so an older link now validates against a newer id. The applicant who clicked their own bookmark from March is looking at a stranger's completed application — name, date of birth, the last four of an account number, and the uploaded scan of a passport. There is no view log because the resume route was the one endpoint you built before adding request logging, so you cannot say how many times this has happened, to whom, or since when. That last part is the part your customer's compliance officer asks about first.
Is that you?
the verdict is a default, not a law
- The form collects a name, an email and free text, and nothing that appears on an identity document
- Nothing is uploaded — no files at all, which removes most of this page's risk in one decision
- Every field is validated server-side, and the client-side rules are treated as a convenience rather than a control
- Submissions have an expiry from the moment they are written, enforced by a job you can point at
- The form collects government identifiers, financial account details, or health disclosures
- Applicants upload identity documents or statements
- You are embedding this on someone else's site and holding their applicants' data
- There is an e-signature step and no audit trail behind it
If you build it anyway
the checklist, then the prompt that enforces it
- Decide what you refuse to collect before you design a single field. Every sensitive field you leave out is a control you never have to build, and this is the only decision on the page that removes risk rather than managing it.
- Write the deletion path before the submission path. Enumerate every place a submission lands — row, files, extracted fields, downstream CRM, emailed copies, backups — and make erasure one operation over that list.
- Redact at the logging boundary, not in review. Allowlist which fields may ever be logged and drop everything else, because a request-body log line is the most common way this data escapes.
- Resume links get high-entropy, single-use, short-lived tokens bound to the submission and re-verified by email. Never sign a guessable id with a static secret.
- Uploads go to private storage with random keys, short-lived presigned URLs, a content-type allowlist and a size cap. Scan them, and never serve them from a path that can be enumerated.
- Validate on the server and treat the client rules as decoration. The embed's API endpoint is public whether or not you documented it.
- Give every submission a retention clock at write time and enforce it with a scheduled job. Abandoned partial submissions expire faster than completed ones, because those people did not choose to apply.
- If there is an e-signature, capture what makes it evidence: signer identity, IP, user agent, timestamp and a hash of the exact document version, stored immutably.
I am building a multi-step application form. The form itself is easy; the data in it
is the problem. Build in this order and refuse to reorder it.
1. First, ask me what the form collects and tell me which fields you would refuse to
store at all. Government identifiers, financial account numbers, ID scans and health
disclosures each need a specific justification from me before you add a field.
2. Build deletion before submission. Enumerate every destination a submission reaches —
database row, uploaded files, extracted fields, downstream integrations, emailed
copies — and implement erasure as one operation across all of them. Prove it with a
test that searches for the value afterwards.
3. Redact at the logging boundary next. Allowlist the fields that may be logged and drop
the rest. Never log a request body from this form, and say out loud that this is the
most common way an SSN ends up somewhere it should not be.
4. Then validation, on the server. The public endpoint behind the embed accepts anything;
client-side rules are a convenience for the user, never a control.
5. Then uploads, if I insist on them: private storage, random keys, presigned URLs that
expire in minutes, a content-type allowlist, a size cap, no enumerable paths.
6. Save-and-resume uses a CSPRNG token, single use, short expiry, bound to the submission
and re-verified against the applicant's email. Do not sign an incrementing id with a
static secret — if I ask for that, refuse and explain the cross-applicant leak.
7. Every submission gets a retention deadline at write time, enforced by a job. Abandoned
partial submissions expire sooner; those people did not finish applying.
8. If I add e-signature, capture signer identity, IP, user agent, timestamp and a hash of
the exact document bytes, stored immutably. Otherwise it is a picture of a name.
9. Do not build document parsing or AI field extraction in v1. When I ask, every extracted
value stays flagged as unverified until a human confirms it.
10. Out of scope: payments in the form, storing card details, anything that emails a copy
of the submission to a third party.
11. If I tell you this form is for insurance or financial-services intake, say plainly
that a vendor with SOC 2 and HIPAA attestations is the cheaper answer.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 field on the form appears on somebody's identity document. Feathery quotes the paid tiers privately now, and what the quote covers is SOC 2 Type II, HIPAA, an audit trail, retention controls and a company that will answer your customer's security questionnaire. You are not buying the form builder — you can write that. You are buying the ability to answer, in writing, what happened to an applicant's passport scan.
Export the form definitions as JSON and the submissions as CSV with the files alongside, keyed the same way — and then treat the export itself as the hazard, because a zip of completed applications is the single most dangerous artefact this project produces. Encrypt it, give it an expiry, and never leave it on a laptop. The definitions port to any form builder in an afternoon; the reason this exit is uncomfortable is that the honest migration also means deleting your copy afterwards and being able to demonstrate that you did.
Active open-source survey and experience platform, self-hostable so submissions stay on your own infrastructure.
Open-source form and API platform with JSON-defined forms, conditional logic and server-side validation built in.
Questions
canivibecodeit says one sitting. Are you disagreeing?
Not at all — they are answering whether an agent can build it, and it can, faster than their estimate suggests. That is exactly why the entry scores where it does. The build being trivial is what makes it likely you will actually do it, and the data it collects is what makes that a problem. Easy to build and bad to own is the shape of a trap, not a contradiction.
What if I strip it back to a plain contact form?
Then most of this page stops applying and it becomes a fine weekend. Names and email addresses, no file uploads, server-side validation, a retention job. The risk here is not the concept of a form, it is the specific fields Feathery's market requires: identifiers, financial details, uploaded documents and medical disclosures on insurance applications.
Isn't the document-extraction feature the interesting part to rebuild?
It is the fun part and the worst one to get wrong quietly. An extractor reading an account number off a photographed statement is confidently wrong on a smudge, and the extracted value flows into a workflow nobody re-reads against the original. If you build it, keep every extracted field marked unverified until a human confirms it against the source document, and never let an unconfirmed value trigger an action.
- GDPR Art. 5 — principles relating to processing of personal data (EU)
- GDPR Art. 32 — security of processing (EU)
- FTC Safeguards Rule — what your business needs to know (US)
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.
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