Should I vibe code
Hosted forms, rules, payments, reports, and notifications
A public upload field is a stranger writing files to your domain. Serve one back inline and it's their page.
?
Their verdict, the Starter 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 part and always was: a page, a POST, a table, an email. What makes Wufoo's shape of form different from a contact box is the two features sitting halfway down its cheapest paid plan. File uploads mean an anonymous stranger can write bytes to your storage, and the obvious implementation serves them back from your own domain under a filename they chose — which is how a form on your marketing site starts hosting somebody else's HTML page, and how your domain ends up in a reputation blocklist you did not know existed. Notification emails mean your server sends mail containing content a stranger typed, to an address configured in a UI, from your sending domain; get the reply-to or the recipient list wrong and you have built a small open relay with a form on the front. Underneath both is the thing Wufoo is genuinely for: registrations, order forms, volunteer applications and event signups that quietly become an organisation's system of record for years, in a table nobody exports and nobody has a deletion policy for. The build is an evening. The custody is the commitment.
What actually breaks
not "if". the specific failures.
- The upload handler, which accepts the filename the browser sent and writes it under your web root, so a stranger now controls a path on your domain
- The download route, which serves that file with the browser's guessed content type instead of an attachment disposition, turning an uploaded HTML file into a page on your origin
- The notification email, whose reply-to is populated from a field the respondent filled in, which is header injection with a friendly label
- Your sending reputation, once a spammer notices that submitting the form makes your domain send mail containing text they wrote
- The entries table, which is the system of record for an event, a membership or an application process and has no export anybody has ever run
- Form rules, where a condition hides a required field and a whole class of respondent cannot submit at all — a bug that produces silence rather than errors
- Storage, which grows one CV at a time until the volume is full at the least convenient moment, because nobody put a quota on an unauthenticated writer
- Payments, the moment you add them, at which point a total computed in the browser is a price the buyer selected
The form was a volunteer application for a small charity: name, email, availability, and a box for a CV. Uploads landed in a directory served straight off the site because that was the shortest path from working to done, and the file kept the name the browser gave it. Directory listing was off, so the paths were effectively private, right up until the confirmation page started linking the uploaded file back to the applicant so they could check it had arrived — and a crawler followed one of those links from a shared screenshot. What surfaces is not a breach notification but a support email from a volunteer who searched her own name and found her CV, complete with her home address, as the second result. There is no deletion endpoint because the entries table was always going to be read by hand, and the file is now in two caches you do not operate.
Is that you?
the verdict is a default, not a law
- The form takes text, nothing else, and no field accepts a file
- It is internal, behind a login, for an audience that could walk to your desk
- Notifications go to one hard-coded address that no form editor can change
- You have written down when entries get deleted, and something actually deletes them
- Losing every submission would be an annoyance rather than an incident
- Strangers can upload files and you have not decided where those bytes live, under what name, and who may read them
- The notification recipient or reply-to is assembled from anything a respondent typed
- The entries are the record for something real — a registration, an application, an order — and nothing exports them
- It takes payment, in which case read the Paperform entry before you write a line
- Nobody owns it in a year, which for a form on a live site is the normal case rather than the pessimistic one
If you build it anyway
the checklist, then the prompt that enforces it
- Uploads go to object storage under a random key you generated, never under the client's filename, never under your web root. Store the original name as metadata and nothing more.
- Serve every file back through an authenticated route with Content-Disposition: attachment and an explicit content type from your own allowlist. Never let the browser sniff a stranger's file on your origin.
- Put uploads on a different hostname from the app if you can, cap size and count per submission, and set a per-form storage quota that refuses rather than warns.
- The notification recipient list is configuration, not input. Nothing typed into a form may reach a To, Cc, Reply-To or Bcc header — build the reply as a link into your admin instead.
- Rate limit per IP and per form, add a honeypot and a minimum time-to-submit, and leave the seam where a real bot check goes before you launch rather than after the first spam wave.
- Write the export before the form: entries plus field definitions plus uploaded files, as one bundle, on a schedule. A submissions table without the schema that produced it is unreadable within a year.
- Give every form a retention setting with a default that is not 'forever', and make the deletion job remove the row, the files and the emailed copies together.
- Walk every branch of the rules with a test. A rule that hides a required field is invisible to the person who wrote it and fatal to the respondent who hits it.
I am building a hosted form tool: forms, conditional rules, notification
emails and file uploads, filled in by strangers. Treat the uploads and the
email as the dangerous parts, because they are, and build them last and
carefully. Argue with me if I want the quick version.
1. Start with the data model and the export. Entries, field definitions and
files must be exportable as one bundle from the first working version, and
there is a test that reimports it.
2. Every form has a retention setting. Default it to 12 months, not forever,
and write the job that enforces it — deleting the row, the files and any
emailed copies together — before the form accepts real data.
3. Text-only fields in v1. No uploads yet. Get validation, storage and export
right on the boring version first.
4. When uploads land: object storage, random keys, never the client filename,
never under the web root. Original name is metadata. Enforce a size cap, a
count cap and a per-form quota that refuses.
5. Files are served only through an authenticated route, with
Content-Disposition: attachment and a content type from my allowlist. Never
inline, never sniffed. If I ask for a public link, explain what an uploaded
HTML file on my own domain does to me.
6. Notification recipients are configuration. No value a respondent typed may
reach To, Cc, Bcc or Reply-To. Refuse if I ask for "just reply to the
submitter" and offer a link into the admin instead.
7. Spam defence ships with the first public form: per-IP and per-form rate
limits, honeypot field, minimum time-to-submit, and a seam for a real bot
check.
8. Server-side validation is against the stored field definitions, never
against what the client claims the form contained.
9. Conditional rules get an enumerated-path test: no path may require a field
the respondent was never shown, and none may loop.
10. Every submission gets a reference and the respondent gets an emailed copy.
That receipt is how they tell me when my side lost their data.
11. One deletion operation removes a respondent's entry, their files and their
exported copies together, proven by a test.
12. Out of scope unless I ask twice: payments, e-signature and anything that
computes a total. If I ask for payments, tell me to read the Paperform
entry first.
13. Finish by telling me what a hosted form product costs a month and which of
the above it has already done.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
For anything public, and Starter is $22 a month billed monthly. What you are buying is mostly custody: storage that is not your web root, spam handling, an entries UI someone else keeps working, and an organisation that answers when a respondent asks for their data back. Be clear-eyed about what you are not buying, though — Wufoo's public release notes stop at August 2020, and while the help centre and status page are current, this is a product being kept running rather than developed. If your form is the front door of something that matters, that argues for one of the actively built alternatives rather than for building your own; the reason to buy has always been custody, and custody is the one thing a homemade form is worst at.
$22/mo is cheaper than your weekend.
Export the bundle, not the table: entries as newline-delimited JSON with the field definitions that produced them, files as a directory of blobs with a manifest mapping keys to submissions, and the form definitions as JSON in version control. A CSV alone rots the moment somebody edits a question, because the columns shift and nothing records that they did. Keep the public form URLs stable and be ready to redirect them at whatever replaces you — an embedded form on someone else's site outlives your interest in maintaining it. And run one real restore before you need one; an export nobody has reimported is a hope, not a plan.
Actively developed open-source form builder with logic, uploads and notifications — the closest thing to this product with a licence attached.
Open-source survey and form platform, useful as a reference for how the storage and retention side is normally organised.
Questions
Is Wufoo still being developed?
It is being operated. The status page and the SurveyMonkey-hosted help centre are current, support exists, and the product works — but the public release notes page, headed 'we're constantly working to make Wufoo the best forms solution out there', has its most recent entry dated August 2020. Draw the obvious inference carefully: this is a twenty-year-old product in a stable state, not an abandoned one. It does change the buy argument, because what you are paying for is custody and continuity rather than a roadmap.
Why is this harsher than the Typeform entry?
Uploads and email. Typeform's risk is mostly about partial answers and a survey nobody completes; Wufoo's cheapest paid plan hands strangers a file upload and hands you an outbound mail path with respondent-controlled content in it. Those two are the difference between holding data badly and offering an anonymous write endpoint on your own domain. Everything else about the two builds is roughly the same evening's work.
What is the smallest safe version?
One text-only form, defined in a file, validated server-side, writing to one table, notifying one hard-coded address, with a honeypot, a rate limit, a retention setting and an export that has been reimported once. That is an evening and it covers most internal use. Uploads, configurable notification recipients and payments are the three additions that turn it into a system with strangers in it, 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.
If the total is computed in the browser, your order form has a price field. Someone will find it before you do.
The approval link in that email is a password. Yours is the row id, and the row is somebody's HR file.
A form is easy. A form that receives strangers’ data and does not get spammed is less easy.
last reviewed 2026-08-05 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice