Should I vibe code
Build conversion-focused landing pages and connect form submissions to email
A public form is a database strangers can write to. Yours also emails you the contents and has no backup.
?
Their verdict, the Grow 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 page is not the problem. A landing page is HTML and an agent writes a good one in an afternoon, which is exactly why this ends up built. The problem is what the page is for: a form, on the open internet, with no authentication, writing strangers' names, emails and phone numbers into a database you set up on a Tuesday. From that moment you are running an unauthenticated write endpoint that bots will find within days, a list of other people's personal data with your own login in front of it, and — worst of the three — a submit handler whose failure is completely invisible. Nobody complains that your form did not work. They fill it in, see "thanks", and leave, and the lead is gone in a way no backup recovers because it was never written down anywhere.
What actually breaks
not "if". the specific failures.
- The submit handler that catches its own exception, returns 200 and renders the thank-you page anyway — the visitor is gone, the row was never written, and nothing anywhere records that somebody tried
- The unauthenticated POST endpoint, which bots find within days of the certificate hitting the transparency logs, and which then fills your table with garbage and your notification address with mail until your own provider throttles you
- Notification email used as the system of record, so the leads exist only in an inbox, unsearchable, unexportable and one filter rule away from invisible
- The admin list view, which is thousands of strangers' names, phone numbers and messages behind whatever session handling got written that evening
- Backups, which nobody configures for the leads table until the week after the migration that truncated it
- Consent, which is a checkbox that was never stored — so when the follow-up sequence goes out you cannot show what anyone agreed to, or when
- The thank-you redirect that takes a URL parameter, turning your branded campaign domain into an open redirect somebody else's phishing run will happily borrow
The campaign goes live on Thursday with four hundred dollars a day behind it. On Friday afternoon you add a "company size" field, deploy, and the insert starts failing a NOT NULL constraint on the old column you forgot to drop. The handler catches the exception, logs a line nobody is watching, and still returns the 200 that renders the thank-you page — so every visitor sees "thanks, we'll be in touch" and closes the tab. On Monday the client asks for the weekend's leads. There are none. There is no way to get them either: the rows were never written, the notification emails fire after the insert so none were sent, and the only people who know they applied are the ninety strangers waiting for a call that is not coming.
Is that you?
the verdict is a default, not a law
- It is a static page with no form on it at all
- The form posts directly to a hosted form service or an email provider you did not write, and your code never stores a submission
- The only field is an email address on a coming-soon page, and losing the lot would genuinely not matter
- It is your own project, your own traffic, and nobody is spending money to send people to it
- You wrote the submission endpoint, the storage and the admin view yourself
- The leads are worth more than the page is — which, if there is ad spend behind it, they are
- It is a client's campaign, so the people whose data you are holding have no relationship with you at all
- There is no alert when submissions fall to zero, and no second copy of a submission anywhere
- You cannot say what wording each person agreed to, and when
If you build it anyway
the checklist, then the prompt that enforces it
- Write every submission twice, to two systems that fail independently: your store, plus a hosted form provider, an append-only log or a mailbox you actually read. Double-writing is the single change that turns a silent loss into a recoverable one.
- The handler fails loudly. A failed insert returns an error to the visitor and pages you — never a 200 with a thank-you page over a swallowed exception.
- Alert on absence, not just on errors. Zero submissions in six hours on a live campaign is the signal, and it is the only one that catches the failure above.
- Rate-limit by IP and put a challenge on the form before launch, not after the first spam wave. An unauthenticated write endpoint on a public domain is found in days.
- Store consent as data — timestamp, source URL, IP and the exact wording shown — rather than as membership of a list. If the follow-up is marketing, that record is the whole defence.
- Put a real identity provider in front of the admin view. Thousands of strangers' phone numbers do not belong behind a session cookie you wrote yourself on a Tuesday.
- Build the CSV export and a scheduled backup of the submissions table before you build the second template. Retention and deletion come from the same code path.
I am building landing pages that collect form submissions from the public.
The page is trivial; the form is not. Two failures matter — silently losing a
lead, and holding strangers' personal data badly. Do the collection path
first and refuse to move on until it is right.
1. Before any page builder or template work, build the submission path and
make it fail loudly. A failed write returns an error to the visitor. Never
return 200 with a thank-you page over a caught exception — that is how a
weekend of leads disappears with nobody noticing.
2. Write every submission to two independent places: my store, and a sink I
do not control (a hosted form provider, an append-only log, a real
mailbox). Confirm both before responding.
3. Add an alert on absence: zero submissions in six hours on a live page is a
page-me event. Absence of errors is not evidence of success.
4. Rate-limit per IP, add a challenge, cap field lengths and reject
oversized bodies before launch. Assume bots find this endpoint within days.
5. Store consent as data — timestamp, page URL, IP and the exact wording
shown next to the checkbox — not as a boolean or as membership of a list.
6. Build CSV export and a scheduled backup of the submissions table before
the second template exists. Deletion of a single person's record uses the
same code path.
7. Put an established identity provider in front of any view that lists
submissions. Do not hand-roll sessions for a page showing thousands of
strangers' phone numbers.
8. No user-supplied URL is ever used for a redirect after submit. Use a fixed
allowlist, and tell me that an open redirect on a campaign domain gets
borrowed by phishing runs.
9. Never log full submission bodies. Log an id and an outcome.
10. Out of scope, and say so: A/B testing, analytics, and anything that emails
the list afterwards. If I want those, tell me Leadpages is $99 a month and
that this is the part where paying 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
The moment there is ad spend behind the page, or the moment the leads belong to a client. $99 a month is roughly a day of a modest campaign budget, and what it buys is a submission pipeline that has already been hit by every bot on the internet, a form that fails visibly, and an export you can hand over when the relationship ends. Losing one weekend of leads costs more than the year.
$99/mo is cheaper than your weekend.
The pages are disposable and the submissions are not. Keep the submissions table exportable as CSV from day one, keep the consent record in the same export, and keep a second copy landing somewhere you do not maintain. Moving to a real platform is then an import rather than an archaeology project — and if the incident comes first, that export is also the only way to tell the people affected which of them were affected.
Active open-source visual website builder built around web standards.
Open-source forms and surveys with submission storage — the half of this that is actually dangerous, already built.
Questions
It's one page with a name and an email box. Is that really YOUR FUNERAL?
The page is not, and if the form posts straight into a service you did not write, neither is the whole thing — that is the SHIP IT case at the top. The verdict is for the version people actually build, where the endpoint, the storage and the admin list are all yours. That version fails silently, is publicly writable, and holds a growing pile of other people's contact details.
Why is silent loss worse than a leak here?
Because a leak is at least discoverable. A dropped submission leaves no trace anywhere: the visitor saw a thank-you page and moved on, no row exists, no error reached anyone. You find out when someone asks why the campaign produced nothing, by which point the traffic is spent and the people are unreachable. That is why the guardrails start with alerting on zero rather than on errors.
Does a form really pull GDPR into a side project?
A name, an email and an IP address are personal data, and collecting them makes you the controller regardless of the project's size. The practical obligations are unexciting and concrete: know your lawful basis, keep only what you need, be able to produce or delete one person's record, and secure it appropriately. All of that is much easier to build in on day one than to retrofit after the first request arrives.
- GDPR Art. 5 — principles relating to processing of personal data
- GDPR Art. 32 — security of processing
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.
Personalization means your headline is a URL parameter. So is the phishing copy somebody else renders on it.
The client leaves. The CNAME stays. Their subdomain now points at a bucket anyone can go and claim.
Every tier is priced in visits. That is the tell — you are not buying an editor, you are buying somebody's CDN.
last reviewed 2026-08-04 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice