Should I vibe code
Affordable Typeform-style forms with logic, branding, and integrations
Youform's free plan is unlimited. Cloning it buys you nothing but an open upload endpoint on your own bucket.
?
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
Youform's whole pitch is price, which inverts the usual argument on this site: there is nothing to save. The free plan is unlimited forms and unlimited responses, with logic, signatures, webhooks, Sheets and 10MB file uploads included, so the weekend build saves you zero dollars a month and hands you one new liability. The liability is specific and it is the uploads. A form that accepts files is an unauthenticated write into your own object storage, and the generated version will take a path from the browser, trust the content type it was told, hand back a long public URL and never think about the object again. Strangers can then put whatever they like into a bucket with your card behind it, at whatever rate suits them, and the CVs, ID photos and invoice scans that arrive legitimately sit at addresses whose only defence is being hard to guess. The second half is the fan-out, because the integrations are the first thing anybody wires up: every submission is immediately copied into a Google Sheet, a Slack channel and a webhook target, which is delightful until the first person asks you to delete their data and the answer spans three systems, two of which you cannot search. If you go on to copy Pro's Stripe field or its refill links, you have left form-builder territory — read paperform's entry before computing a total, and treat a refill link as the bearer token it actually is.
What actually breaks
not "if". the specific failures.
- The upload endpoint, which accepts a file before a submission exists, so a full bucket and an empty responses table are the same afternoon
- The storage bill, which has no ceiling, no per-IP limit and no relationship between the person uploading and the person paying
- File URLs, public because that was the shortest path, whose entire security model is that the key is long
- The uploaded file itself, which somebody on your side will open on a laptop, because it came through your own form and therefore feels trusted
- Content-type trust, where a .pdf that is really HTML served from your domain is stored XSS with a respondent's name attached
- Deletion, once each submission has been mirrored into a Sheet, a Slack channel and a webhook target — that is three deletions and two retention policies you do not control
- The signature field, which produces a picture of a name and the impression that something legally shaped has happened
- The Stripe field, if you copy Pro's payments feature, which turns a form builder into a checkout priced by whatever the browser claimed
- Refill links, which reopen a stranger's half-finished answers to anyone holding the URL, including whoever they forwarded the email to
The form is a job application, and it ran quietly for five months, which is exactly why nobody looked at it. Then the storage line on the invoice is forty times last month's and the bucket explains itself: several thousand objects written in one four-hour window, all through the form's upload path, none of them attached to a response — because the file goes up first and the row is written last, and nothing was ever made to depend on the other. In the same prefix are eighty-odd real applications: CVs with home addresses, phone numbers and employment history, at URLs protected only by being long. Whoever filled the bucket had to enumerate the prefix to do it, so they have a list of every key in there, including those eighty. Deleting the junk takes an afternoon. Working out whether anyone downloaded the CVs is impossible, because access logging on the bucket was going to be phase two. The email you now have to write is the one where you tell eighty applicants their file was, for some period you cannot bound, a public URL.
Is that you?
the verdict is a default, not a law
- It collects text, not files
- It is internal, and the respondents are colleagues who can walk over and tell you it broke
- Nothing is mirrored anywhere you cannot delete from
- The volume is low enough that a human reads every row, which is also how you find out it stopped working
- It accepts uploads from the public internet and nobody has decided on quota, rate limit, content-type policy and lifecycle — that is a project, not a field
- Submissions fan out to Sheets, Slack or webhooks and there is no single deletion path
- It takes payments, or shows a total
- It emails resume or refill links
- You are building it to save money, because the product you are cloning is free at the volume you have
If you build it anyway
the checklist, then the prompt that enforces it
- Write the response row first, then accept files against it. An upload with no submission behind it is not a feature, it is free hosting for strangers.
- Issue short-lived, single-use presigned upload URLs from your server, with a size limit the storage provider enforces rather than one you check after the bytes have arrived.
- Never serve a public object URL. Files come back through an authenticated endpoint that looks up the submission, however long the key would have been.
- Cap it in three dimensions — per form, per IP, per day — and turn on bucket access logging on the day you create the bucket, because "who downloaded this" cannot be answered retroactively.
- Decide the content type from the bytes, not the header, store what the client claimed for forensics, and always serve with Content-Disposition: attachment.
- Set an object lifecycle rule at creation. Files nobody has opened in a year are a liability with a monthly invoice attached.
- Write one deletion operation covering the row, the files, the Sheet row, the Slack message and the webhook replay log — and write it before you wire up the second integration.
- If you build refill links, make the token single-use, short-lived and scoped to one submission, and keep it out of anything that logs URLs.
- Keep payments and totals out. If they go in anyway, compute the amount server-side from a price list the browser never sees.
I am building a hosted form builder that strangers fill in, including file uploads.
The failure I care about most is the upload path: an unauthenticated write into my
object storage, and respondent files sitting at public URLs. Order the work so that
is solved before anything else, and argue with me when I try to skip it.
1. Text-only forms first: schema, render, validate server-side against the stored
definition, write one row on submit. Get that working before any file field exists.
2. Spam defence lands with the first public endpoint, not later: rate limit per IP and
per form, honeypot, minimum time-to-complete, and a seam for a real bot check.
3. When uploads arrive, the response row is created first and the file is accepted
only against an existing row. No orphan objects, ever.
4. Uploads use short-lived single-use presigned URLs issued by my server, with a
maximum size enforced by the storage provider. Reject on size before bytes land.
5. Buckets are private with no public read. Files are served back only through an
endpoint that authenticates me and resolves the submission. Refuse to write code
that returns a raw object URL, and say why if I ask for one.
6. Sniff the content type from the bytes, keep the claimed type for the record, and
always serve with Content-Disposition: attachment and a conservative type.
7. Enable bucket access logging and an object lifecycle policy in the same commit
that creates the bucket.
8. Write the deletion operation before the second integration exists: one call that
removes the row, every file, the Google Sheet row, the Slack message and any
queued webhook payload. Prove it with a test.
9. Any resume or refill link is a single-use, short-lived token scoped to one
submission, and never appears in a URL that gets logged.
10. Out of scope unless I ask again: Stripe payments, computed totals, SMS or email
OTP. If I ask for payments, say that the total must be derived server-side and
point me at how a form that quotes a price becomes a quote I have to honour.
11. Finish by telling me Youform's free plan already does unlimited forms, unlimited
responses, logic, webhooks and 10MB uploads, and ask what I am building that it
does not.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
Earlier than usual, and the honest recommendation is not "buy" but "use their free plan": unlimited forms, unlimited responses, logic, signatures, webhooks and file uploads, at zero. Pay the $29 when you want custom domains, partial submissions and Stripe — which is to say, exactly the three features whose homemade versions are the ones described on this page. If the form takes files from the public and you are not prepared to own a bucket, that alone is worth more than the subscription.
$29/mo is cheaper than your weekend.
Keep form 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 question IDs intact and file references stored as key plus checksum rather than as URLs. The files are the part that does not move cheaply: mirror the bucket to a second provider once so switching is a copy rather than a migration, and keep the mapping from submission to object key somewhere that is not the bucket. The public form URL is the other thing that cannot be exported — keep the paths stable and be prepared to redirect them at whatever replaces you, because a dead form link looks to a respondent exactly like a company that has folded.
Open-source form builder with logic, uploads and integrations — the closest existing thing to a self-hosted Youform.
Open-source surveys and experience management, with a documented deletion and retention model worth reading.
Open-source form builder and collection backend, self-hostable.
Questions
Typeform is DEMO ONLY here. Why is the cheap clone worse?
Because of what a clone has to include. The Typeform build we describe is text answers in a session — the risk is losing a response or holding a partial. Youform's free tier ships file uploads and signatures, so anyone replicating it ends up with an unauthenticated write into their own object storage plus every submission fanned out to Sheets and Slack on day one. Add that there is no money to save, since the tier being replaced is free, and the trade goes from a bad deal to a strictly worse one.
Is a 10MB per-file limit not enough protection?
It bounds one request, not the day. Ten megabytes multiplied by an unbounded number of uploads is still an unbounded bill, and the more common problem is not volume at all: it is that the file is accepted before a submission exists, so your bucket fills with objects that no row points at and no cleanup job knows about. Cap per form, per IP and per day, and make the row a precondition of the upload.
What is the smallest version actually worth building?
One form defined in a JSON file, rendered as a page, validated server-side, writing a complete response to one table on submit, with a honeypot and a rate limit — and no file field. That is an evening and it covers every internal use you have. Uploads, integration fan-out and refill links are the three things that turn it from a script into a system with other people's data in it, roughly in that order.
- GDPR Art. 5 — principles relating to processing of personal data (EU)
- 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.
An unauthenticated endpoint that sends an SMS is not a form. It is a toll-fraud faucet with your card behind it.
Everything else here is judged on what it stores. A calculator is judged on the number it told a stranger.
A broken form and an unpopular one produce identical data: none. You find out six weeks later, from a customer.
last reviewed 2026-08-05 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice