Should I vibe code
Landing pages, popups, experiments, lead capture, and agency workflows
The client leaves. The CNAME stays. Their subdomain now points at a bucket anyone can go and claim.
?
Their verdict, the Build 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 word doing the damage in Landingi's own description is "agency". A landing page for yourself is a weekend and a small mistake. Landingi's shape is pages you build for other people, published on their domains, capturing their prospects, measured by experiments they will make budget decisions on — and each of those clauses moves the failure somewhere you cannot see it. You end up operating multi-tenant hosting: a system that serves arbitrary HTML and JavaScript, on domains you do not own, behind certificates you have to keep renewing, with an unauthenticated form endpoint per page and a login for every client who wants to check their leads. Then there is the experiment engine, which is the part that looks like a feature and behaves like a liability. A split test without sticky assignment, a fixed sample size and a stopping rule is not a measurement, it is a random number with a confidence interval drawn around it, and it will tell a client to roll out the losing variant in a tone of complete certainty. None of this is hard. All of it is somebody else's business.
What actually breaks
not "if". the specific failures.
- The form endpoint, silently. A landing page that 500s on submit still renders the thank-you state on a generated build, so a campaign keeps spending and the leads simply stop arriving with nothing in the UI to say so
- Custom domains, in both directions: a certificate that quietly fails to renew takes a client's live campaign off the air, and a CNAME left pointing at your infrastructure after a client leaves is a subdomain takeover waiting for whoever notices first
- A/B tests, which mislead rather than break. Without sticky bucketing a returning visitor gets re-randomised and both variants pollute each other; without a pre-declared sample size, watching the dashboard until one line is ahead produces a winner every single time
- The builder's HTML and script blocks, because a page editor that accepts embed codes is a stored-XSS engine, and the domain it executes on belongs to your client
- Tenant isolation in the admin, the moment two clients log in to see their own leads and the account ID is a path segment
- Popups and cookie behaviour, which fire tracking pixels the client's privacy policy has never heard of, on the client's domain, under the client's name
- Lead delivery, when the integration to their CRM fails: the webhook retries three times, gives up, logs nothing, and the leads exist only in a table nobody is watching
- Page performance under an ads spike, since a landing page's entire traffic profile is a step function that starts the minute a campaign goes live
- The archive, because pages are cheap to create and nobody deletes them — two years later you are hosting four hundred pages, and the ones with live forms on them are indistinguishable from the ones without
The client rings on Monday, not because the page is down — it is up, it looks perfect, the ads are pacing beautifully. The problem is that they have spent £6,200 since Thursday and the sheet has nine leads in it, where the same spend in June produced two hundred. You reproduce it on the third attempt: the form posts, your endpoint throws on a payload with an apostrophe in the company name, and the front end shows the thank-you panel regardless because the fetch result was never checked. It has been failing since a deploy on Wednesday evening. There is no queue, no dead-letter table and no error alerting on that route, so the submissions did not fail into anything — they were simply never written. Which means the honest answer to the only question the client is going to ask, how many people did we lose, is that you do not know and cannot find out, and the people who filled in that form believe somebody is calling them back.
Is that you?
the verdict is a default, not a law
- The page is yours, on your own domain, and no client is depending on it
- The form posts to a service you already trust with the rest of your leads rather than to a table you set up on the day
- There are no experiments, or the experiment is a decision you would be equally happy making by eye
- It is a campaign with an end date, and taking it down is part of the plan rather than a thing nobody gets round to
- Nothing on the page executes markup pasted in by somebody else
- The pages sit on domains belonging to clients, which makes their DNS, their certificates and their uptime your on-call rota
- Two clients log in to the same deployment to look at their own leads
- A budget decision will be made from your split-test result
- The leads are personal data you hold on behalf of someone else and nobody has written down which of you is the controller
- You cannot say, for any given hour last week, whether every submitted form actually landed in the database
If you build it anyway
the checklist, then the prompt that enforces it
- Make the submit path fail loudly. Check the response on the client, show a real error, and write every submission to a durable queue or an append-only table before any processing — a lead that never reaches storage is the only failure on this page that is genuinely unrecoverable.
- Alert on absence, not just on errors. A rule that fires when a live page's submission count drops to zero for an hour catches the incident above; nothing else does.
- Own the DNS lifecycle. Track which client domains point at you, verify ownership before serving a hostname, and make removing the CNAME part of offboarding — a dangling record on somebody else's domain is a takeover primitive with their brand on it.
- Automate certificates and monitor expiry independently of the thing that issues them. Renewal failures are silent right up to the moment a campaign is dark.
- Derive the tenant from the server-side session on every request. Never from a path segment, a query parameter or a hidden field, because a leads dashboard is a multi-tenant application whatever it looks like.
- Sanitise or sandbox anything the editor lets a user paste. Custom HTML and script blocks execute on a domain you do not own; iframe them with a restrictive sandbox or do not offer them.
- If you run experiments, do it properly: hash the visitor ID into a stable bucket, declare the sample size and the metric before starting, and refuse to report a winner early. A dashboard you can watch is a dashboard you will peek at.
- Enumerate every consent surface on the page — form checkbox, cookie banner, tracking pixels — and agree in writing with the client who is the controller, before the page goes live rather than after the first complaint.
- Give pages a lifecycle: an owner, a launch date and an expiry, so the archive of forgotten pages with live forms on them never accumulates.
I am building a landing-page platform: pages I publish for clients, on their
domains, each with a lead form, plus a dashboard where they see their own leads.
Build it in this order and argue with me where noted.
1. Start with the submit path, before any page rendering. Write every submission
to durable storage first, then process. The client-side code must check the
response and show a real error — never render a thank-you state on a failed
request. If I ask you to fire and forget, refuse and explain that lost leads
cannot be recovered or even counted.
2. Add monitoring for absence next: alert when a live page's submissions drop to
zero over a window, and put failed deliveries in a dead-letter table I can see.
3. Then tenancy. The client identifier comes from the server-side session and
nowhere else — never a path segment, query parameter or hidden field. Write
the negative test first: as client A, request client B's leads by ID and
assert an empty response.
4. Then domains. Verify ownership before serving a custom hostname, keep a record
of every hostname pointing at my infrastructure, and give me an offboarding
checklist that includes removing the CNAME. Explain subdomain takeover to me
in two sentences so I take that step seriously.
5. Certificates are automated, and expiry is monitored by something other than
the issuer.
6. Treat any custom HTML, script or embed block the editor accepts as hostile.
Sandbox it in an iframe with a restrictive policy, or tell me you are not
building that feature.
7. Only then A/B testing, and only with sticky bucketing from a hash of a
persistent visitor ID, a sample size declared before the test starts, and a
refusal to display a winner before it is reached. If I ask which variant is
winning on day two, say no and explain peeking.
8. Rate-limit and bot-check every public form endpoint, and pin CORS to the
hostnames I have actually registered.
9. Give every page an owner and an expiry date, and make an unattended page with
a live form on it something the dashboard flags.
10. Out of scope for v1: a drag-and-drop editor, popups, email sequencing and
CRM sync. And say plainly that if these pages carry other people's campaigns,
$29 a month for a platform that has already handled all of the above is the
cheaper form of professionalism.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 pages carry a client's campaign rather than your own. $29 a month is trivially less than one afternoon of an agency's time, and it buys the specific things this page is a list of: durable lead capture with retries, managed certificates for domains you do not control, a tenant boundary in the client dashboard that somebody else has already been attacked through, and an experiment engine that will not let you peek. Build your own pages. Do not build the platform that other people's revenue runs on.
$29/mo is cheaper than your weekend.
Pages are the easy part — they are HTML, and static HTML outlives every platform it was built in, so export them and keep the assets alongside. The hard part is everything with someone else's name on it. Export the leads per client and hand them over in a form they can actually import, because those records were never really yours. Then walk the domain list: every client hostname pointing at your infrastructure needs its CNAME removed at their end before you tear anything down, and that requires an email to each of them rather than a deploy. Keep the experiment history too, since a client who spent money on a result will ask what it was based on. The shutdown that goes wrong is not the one that loses pages, it is the one that leaves four abandoned DNS records pointing at nothing.
Actively developed open-source visual website builder that publishes real static output.
Long-running open-source web-builder framework, the usual foundation if you insist on writing the editor half yourself.
Questions
How is this different from your Leadpages entry?
Leadpages is about the form: an unauthenticated write endpoint on the open internet, collecting strangers' details into a table you made on a Tuesday. Everything there applies here too. What Landingi adds is the agency layer — client domains, client logins, client experiments — so the same bugs now land on a business that hired you, and the DNS and certificate lifecycle for hostnames you do not own becomes a thing you operate rather than a thing you configured once.
What is actually wrong with my A/B test?
Usually two things, and both produce results that look fine. If assignment is not sticky, a visitor who returns gets re-randomised and their behaviour is smeared across both variants. And if you decide when to stop by looking at the dashboard, you will find a significant result eventually whether or not a difference exists — that is what repeated peeking does to a p-value. Fix both by hashing a persistent visitor ID into a bucket and writing down the sample size before you start.
Is the dangling CNAME thing really a problem?
It is one of the most reliably exploited misconfigurations there is. A client points marketing.theircompany.com at your platform, then leaves; you delete their account but their DNS record still resolves to your provider. Anyone who can claim that hostname on the same provider now serves content from their subdomain, with their brand and whatever cookies are scoped to it. The fix is process rather than code: verify hostnames on the way in, and chase the record's removal on the way out.
Who is the data controller for leads I collect for a client?
Almost always them, with you as the processor — which is fine, and which is exactly why it needs writing down before the first campaign. The processor role comes with obligations about instructions, sub-processors, security and deletion, and the client will need your name in their own records. An agency that has never had that conversation typically discovers it during a client's security review, which is a worse time.
- GDPR Art. 5 — principles relating to processing of personal data (EU)
- GDPR Art. 28 — processor obligations (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.
A public form is a database strangers can write to. Yours also emails you the contents and has no backup.
Personalization means your headline is a URL parameter. So is the phishing copy somebody else renders on it.
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-05 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice