Should I vibe code
Landing pages, personalization, experiments, collaboration, and analytics
Personalization means your headline is a URL parameter. So is the phishing copy somebody else renders on it.
?
Their verdict, the Create 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
Instapage is not sold as a page builder, it is sold as the thing that sits between an ad and a conversion — dynamic text replacement, ad-to-page mapping, split tests, visitor analytics. Rebuild that and you inherit three problems the page itself never had. Dynamic text replacement is, mechanically, rendering a URL query parameter into your headline, which means anyone who can write a link controls the copy on your branded domain and can pay to put that link in front of people. Split testing without sticky assignment and a stopping rule is not measurement, it is a random number generator you keep consulting until it agrees with you, and the budget you reallocate on its answer is real. And the page is where the money physically lands, so an outage is not downtime, it is dollars a minute flowing into an error screen with an ad platform quietly noting the bounce rate. None of it is hard to build. All of it is expensive to get wrong, and the people paying are the visitors and whoever funded the campaign.
What actually breaks
not "if". the specific failures.
- Dynamic text replacement, the moment somebody other than you writes the URL — an unfiltered parameter in a headline lets a stranger publish their sentence, their phone number and their urgency on a domain that carries your logo and your TLS certificate
- Variant assignment, if it is not sticky and not server-side — a returning visitor lands in the other arm, both samples are contaminated, and the test reports a winner with total confidence
- The stopping rule, which nobody writes: checking significance every morning and stopping the first time it crosses is how you ship the losing variant and then defend it for a quarter
- Availability under real traffic, which is a different shape from your usual load — campaign traffic arrives as a spike, and a landing page that 502s during it is burning budget at whatever the daily rate divides into
- Attribution, quietly, when a redirect or a canonical tag strips the click identifier and the ad platform stops being able to see the conversions you are optimising against
- The form, in all the ways the Leadpages entry describes — swallowed exceptions, no backup, a public write endpoint — because that part is identical here
- Consent and tracking, since personalisation by UTM plus a visitor-level analytics cookie is exactly the processing that needs a lawful basis and a record of what the visitor was shown
The personalisation feature is three weeks old and works beautifully: whatever keyword the visitor searched for gets rendered into the headline, so a campaign for one product can serve a hundred variations of the same page. On a Tuesday your support address gets a message from someone asking why your company is telling them their account is suspended and instructing them to call a number. The link they were sent is genuinely yours — your domain, your certificate, your logo — with a query parameter carrying the entire message, which your template obligingly renders in 42-point type at the top of the page. The messages were sent by SMS to several thousand people. You can fix the template in ten minutes; what you cannot fix is that the URL is already out there, that it is indexed, that your brand was the credibility in the scam, and that the security questionnaire you fill in for your largest client asks whether you have had an incident.
Is that you?
the verdict is a default, not a law
- The page is static, has no form, and takes nothing from the query string
- There is no ad spend behind it — organic traffic only, and losing a day of it costs nothing
- Any A/B split is a decision you would be comfortable making by coin flip, because that is roughly the information content of an underpowered test
- Submissions post directly to a hosted form service you did not write
- Any part of the page is populated from a URL parameter, referrer or cookie without an allowlist
- You are running experiments and cannot describe your assignment mechanism, sample size and stopping rule in one sentence each
- There is real ad spend pointed at it and no uptime alerting on the page itself
- It is a client's campaign, so the reputational surface belongs to somebody who did not review your code
- The form, the storage and the admin view are all yours — that is the Leadpages verdict, and it applies here unchanged
If you build it anyway
the checklist, then the prompt that enforces it
- Never interpolate a URL parameter into the page. If personalisation is required, map parameter values to an allowlist of pre-written copy on the server, so the worst an attacker can supply is an unrecognised key that falls back to the default headline. Escaping is not the fix here — the attack works fine with plain text.
- Make experiment assignment server-side, sticky and hashed on a stable identifier, and write the assignment to the conversion record. A test where you cannot prove which arm a conversion belonged to is not a test.
- Fix the sample size and the stopping rule before the experiment starts, and refuse to look at significance before then. Peeking is the difference between a result and a story.
- Add a sample ratio check that alarms when the split drifts from what you configured. It is the single cheapest way to discover that your assignment logic is broken, and almost nobody adds it.
- Alert on the page itself, not just on the server: an external check every minute, plus an alert on conversions falling to zero while ad spend continues. Spend is the thing running in the background whether or not the page works.
- Keep the click identifiers intact end to end and test that a real click still attributes after every redirect or canonical change. Attribution breaks silently and is invisible until the optimisation goes strange.
- Store consent and the exact page variant shown alongside every submission. When a visitor asks what they agreed to, "the version of the headline we were serving that afternoon" needs to be a lookup rather than an archaeology exercise.
I am building landing pages for paid campaigns, with personalisation and A/B
testing. The HTML is not the risk. Three things are: rendering untrusted input
into the page, measuring an experiment wrong, and being down while money is
being spent. Handle them in that order.
1. Refuse to interpolate any URL parameter, referrer or cookie value into page
copy. Build personalisation as a server-side map from a parameter key to
pre-written content, with a default fallback. If I insist on free text, say
that a stranger can then put their headline and phone number on my domain
and pay to distribute the link, and that escaping does not prevent that.
2. Make experiment assignment server-side and sticky: hash a stable visitor id,
persist the arm, and write the arm onto every conversion record. No
client-side coin flips on each page load.
3. Ask me for the sample size and stopping rule before writing the experiment
code, and refuse to build a dashboard that shows running significance. Add a
sample ratio mismatch alarm.
4. Add external uptime checks on the published page and an alert on conversions
at zero while the campaign is live. Ad spend does not pause when the page
500s.
5. Any form posts to a handler that fails loudly, writes to two independent
places, and never returns a thank-you page over a caught exception.
6. Rate-limit and challenge the submit endpoint before launch, cap field
lengths, and reject oversized bodies.
7. Store consent as data alongside each submission — timestamp, page URL, the
variant shown and the exact wording displayed.
8. Redirects use a fixed allowlist. No user-supplied destination, ever.
9. Preserve click identifiers through every redirect and prove attribution
still works with a real click before launch.
10. Out of scope, and say so: a visual page builder, multivariate testing and
audience segmentation. If I want those, tell me Instapage is $99 a month
and that the personalisation engine is the part I would be buying safely.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 somebody else's money is behind the traffic. Ninety-nine dollars is a few hours of a modest campaign, and it buys an experimentation engine that already handles sticky assignment, a personalisation feature that cannot be steered from a URL by a stranger, and infrastructure that survives a spike. Build the static page yourself by all means — it is genuinely an afternoon. Buy the layer that decides what the page says and whether the test was real.
$99/mo is cheaper than your weekend.
Pages are disposable; the submissions, the consent records and the experiment history are not. Keep submissions exportable as CSV with the variant and consent wording attached from the first row, and keep experiment results as a written log — hypothesis, sample size, arms, outcome, decision — rather than as a dashboard that recomputes. The dashboard dies with the app. The log is the only thing that stops the next person rerunning a test you already ran and getting the opposite answer.
Active open-source visual website builder built on web standards.
Open-source feature flags and A/B testing with proper assignment and statistics, which is the half of Instapage worth not writing.
Open-source web builder framework, if the drag-and-drop editor is what you were after.
Questions
How is this different from the Leadpages verdict?
Leadpages is about the form: silent submission loss, a public write endpoint, a growing table of strangers' contact details. All of that applies here too and is not repeated at length. What Instapage adds is the layer above the page — personalisation driven by URL parameters, and experiments that reallocate a real budget — and both of those have failure modes the form does not.
Is dynamic text replacement really a security issue? It's only text.
Text is the attack. You do not need script execution to do damage when the payload is a sentence: the value comes from the fact that the sentence appears on your domain, under your certificate, next to your logo. An attacker writes the headline, adds a phone number, and distributes the link by SMS or by buying ads against it. Escaping the value stops the XSS and does nothing about the phishing, which is why the fix is an allowlist rather than a sanitiser.
What is actually wrong with a homemade A/B test?
Usually three things at once. Assignment is not sticky, so people move between arms and both samples are polluted. There is no fixed sample size, so significance is checked daily and the first crossing is treated as an answer. And nothing checks whether the split actually came out 50/50, which is the cheapest available signal that the assignment code is broken. The result is not a slightly noisy answer, it is a confident wrong one that then directs spend.
Can I not just build the page and skip the clever parts?
Yes, and that is the good version. A static page with no query-string personalisation, no experiment and a form that posts straight into a hosted service is close to the SHIP IT case at the top of this entry, and an agent writes it in an afternoon. The verdict is for what people build next, in week three, when the campaign manager asks whether the headline can match the search term.
- GDPR Art. 6 — lawfulness of processing
- 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.
A public form is a database strangers can write to. Yours also emails you the contents and has no backup.
The client leaves. The CNAME stays. Their subdomain now points at a bucket anyone can go and claim.
Building a website builder is the software equivalent of building your own hammer factory.
last reviewed 2026-08-05 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice