Should I vibe code
Compose branded document-like forms with payments left out of scope
A total computed in the browser is a discount code for anyone who can open devtools.
?
Their verdict, the Essentials 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
What sets Paperform apart from the other form builders here is that the form is a page — your typography, your domain, no visible vendor — and that changes what people do with it. A form that looks like part of your website gets used for order forms, client intake and event registration, and it gets used to tell people things: a running total, a booking slot, a price. That total is where a hobby project turns into a commitment. Compute it in the browser and it is a number the customer can edit before submitting; compute it wrong and you have published a quote on your own domain that somebody will reasonably expect you to honour. Underneath sits the ordinary form problem, which is worse than it looks: an unauthenticated POST endpoint carrying your brand, an upload directory full of files strangers chose, and a notification email that will one day start landing in spam without telling you. Submissions do not fail at that point. They simply stop being read, and the person who filled the form in has no way to know.
What actually breaks
not "if". the specific failures.
- The notification email, which starts going to spam on a Tuesday and takes eleven days to notice, during which the form works perfectly and nobody reads a thing
- A total calculated in the browser and trusted on the server, which any submitter can change to whatever they like before pressing send
- The calculation itself: a discount rule with the wrong comparison, quoting £0 to every customer who ordered more than ten of anything
- File uploads, which are arbitrary bytes from strangers, stored under a filename they chose, and served back from your own domain
- Conditional logic, where a hidden-but-required field blocks submission with no visible error and the visitor simply leaves
- The appointment slot, double-booked because two people picked it in the same minute and nothing held a lock
- Time zones and DST on anything that books a date, so the customer arrives an hour early in October
- Bots, which find a public POST endpoint within days and will fill your database and your inbox for free
The form is the one thing on your site that actually converts: a branded quote request on quotes.yourcompany.com, four conditional sections, a total at the bottom, and an email to sales@ every time somebody submits. In February you move the notification to a new transactional provider because the old one raised its prices. Nothing breaks — the send returns 202, the logs are clean, the test submission you fired arrives. What has actually happened is that the new provider's domain is not in your SPF record, so a portion of receiving servers begin filing your notifications as spam, and one of those receivers is your own company's mail host, which quarantines rather than delivers. Sales reads the shared inbox, not quarantine. The database is fine and has been collecting submissions the whole time. Nobody looks at the database, because looking at the database was never part of anybody's job. Six weeks later a prospect phones to ask why they never heard back about their quote, and the honest answer — that the request has been sitting in a table nobody opens since the second week of February, alongside three hundred others — is not one you want to give.
Is that you?
the verdict is a default, not a law
- The form is internal, or the audience is people you could phone if it broke
- Every submission is written to durable storage first and notified second, and the storage is the record
- Nothing on the form computes a price, books a slot, or tells the visitor anything they might act on
- There are no file uploads, or uploads go to object storage with generated names and are never served from your domain
- The form quotes a price or confirms a booking and you have not re-derived that number server-side from server-held rules
- It lives on your custom domain and looks official, because everything it gets wrong now looks deliberate
- You have no delivery monitoring on the notification path and no habit of reading the table directly
- Uploads are stored under user-supplied filenames and served back from the same origin as your app
- It collects anything you would not want to describe in a breach notification, which for intake forms is almost always more than you planned
- There is no rate limit, no bot defence, and no cap on how many submissions one visitor can make in a minute
If you build it anyway
the checklist, then the prompt that enforces it
- Persist first, notify second. Write the submission to durable storage inside the request, then queue the email. A failed email must never lose a submission.
- Monitor delivery, not sending. Alert on a day with zero submissions when your baseline is not zero, and on notification bounces, because a silent stop is the failure that actually happens.
- Re-derive every price, total and discount on the server from rules the client cannot see. Treat any number that arrived in the request body as a claim, not a fact.
- Give every submission a reference number and email a copy to the submitter. That receipt is what lets them tell you when your side lost it.
- Uploads go to object storage, with a generated name, a content-type allowlist and a size cap, served from a different origin than your app — never from the path they were uploaded to.
- Rate limit by IP and by form, add a timestamp and honeypot check, and expect to add a real CAPTCHA the week the spam starts.
- Book appointments through a unique constraint on the slot, not through a check-then-insert. Store every time in UTC with the origin zone recorded alongside it.
- Decide retention before launch: how long submissions live, who can export them, and what deletes an entry properly when somebody asks.
I am building a branded form builder — document-style forms on my own domain,
with conditional logic, calculated totals and file uploads. Strangers submit
them. Build it so a submission is never silently lost and a total is never
trusted from the browser, and argue with me when I ask for shortcuts.
1. Submission durability first: write to the database inside the request, then
queue notifications separately. Show me what happens when the mail provider
is down — the submission must still exist.
2. Then the monitor. A daily check that alerts me if submissions drop to zero
against a rolling baseline, plus bounce handling on the notification address.
The failure I care about is silent, not loud.
3. Every calculation is re-derived server-side from rules stored on the server.
Prices, discounts, totals and quantities in the request body are untrusted
input. If I ask you to trust the client total, refuse.
4. Uploads: allowlist content types, cap size, generate the stored filename
yourself, keep them in object storage, and serve them from a different origin
through short-lived signed URLs — never from the app's own origin.
5. Spam defence before launch: rate limit per IP and per form, a honeypot field,
a minimum time-to-submit, and a hook where a CAPTCHA goes.
6. Every submission gets a reference number and the submitter gets an emailed
copy of what they sent. That receipt is part of the data model.
7. Conditional logic must never leave a required field hidden. Prove a form
cannot reach an unsubmittable state, and show errors next to the field.
8. Appointment slots are reserved by a unique constraint in the database, not a
read-then-write. Store UTC plus the submitter's zone.
9. Define retention up front: how long a submission lives, who can export it,
and one operation that erases a person's entry everywhere.
10. Out of scope: taking payments. If I ask, tell me to use hosted checkout with
a server-created amount and nothing else.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 the form is public and the submissions matter. $29 a month buys the unglamorous half — durable storage, spam filtering, upload handling, delivery monitoring and the receipt email — which is almost exactly the list of things a homemade version omits and then loses submissions through. Build your own for internal forms, throwaway signups and anything where you would notice within the hour that nobody had replied.
$29/mo is cheaper than your weekend.
Keep the two things that are not really yours to lose: the form definitions and the submissions. Store each form as a JSON definition in version control rather than as rows in a builder table, and export submissions on a schedule to CSV or newline-delimited JSON with the uploads alongside them, named by reference number. Then moving to a hosted tool is rebuilding four forms and importing a file, which is a Saturday. The part that does not migrate is the URL — anything printed, emailed or linked from a partner site points at your domain, so keep the form paths stable and be ready to redirect them to whatever replaces you.
Active open-source survey and experience-management platform.
Open-source rendering engine for forms with conditional logic and calculated values — the fiddly half, already written and tested against real forms.
Questions
Why is this harsher than the Tally entry when both are form builders?
Tally's entry is about becoming a custodian of whatever strangers typed, which is true of every form. This one is about what Paperform-shaped forms do beyond collecting: they compute, they confirm, and they do it on your own domain in your own typography. A form that shows somebody a total has made a statement, and statements are the part people hold you to.
Is the browser-computed total really that common a bug?
It is the default outcome. The natural implementation puts the pricing rules in the client because that is where the live total needs to update, then posts the computed number along with the answers, and the server stores what it was sent. Nothing looks wrong in testing, because testers do not edit the request. Ask for the total to be recomputed server-side from rules the client never sees and the whole class of problem disappears.
What is the smallest version of this I should actually build?
A single form, defined in code, that writes to a table and emails you a copy — plus a weekly job that tells you how many submissions arrived. That is an hour of work and it covers the internal use case completely. Everything past it, in rough order of how quickly it bites, is uploads, calculations, scheduling and public traffic.
- 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.
Survey answers are other people’s opinions with their identity attached. Store them like it.
You never decided to store health data. A dropdown someone added to an event signup decided it for you.
A form is easy. A form that receives strangers’ data and does not get spammed is less easy.
last reviewed 2026-08-04 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice