Launch a landing page with a working signup form

The classic advice for validating an idea is "put up a landing page with a waitlist form and see who signs up". The advice is right. The friction is in the second half: the page itself is easy, but a form that actually delivers signups traditionally meant a backend, a database, or a Mailchimp account you did not want yet. Here is how to do the whole loop, page, domain, and working form, without any of that.

The 48-hour validation loop

The goal is not a beautiful website. The goal is an answer: does anyone want this? The loop looks like this.

Day one: write the pitch, let an AI turn it into a landing page, deploy it, and connect a domain. Day two: put the link in front of people, in communities, in replies, in your bio, and watch the signups arrive. Every hour spent on infrastructure is an hour not spent on the answer, so the setup below is chosen for one property: nothing to build and nothing to maintain.

What you need is exactly three things: a page, a form that reaches you, and a URL credible enough that strangers will click it.

Let the AI build the page

Do not hand-code a validation page in 2026. Describe it to an AI instead: who the product is for, the one-sentence promise, three benefit bullets, and a signup form with an email field. ChatGPT and Claude can produce a clean single-file page from that prompt. Tools like v0 will give you something more designed; the v0 deploy guide covers getting that output live, and the Claude artifacts guide covers Claude's version, where the AI can even do the deploying for you over MCP. Other AI tools and their routes are in the complete deploy guide.

Two prompt tips that pay off. Ask for a single self-contained HTML file, which makes deploying trivial. And ask for exactly one call to action, the signup form, because a validation page with five links measures nothing.

If your draft is running on localhost from a local AI tool, the localhost deploy walkthrough takes it from your machine to a public URL.

The signup form: forms relay explained

This is the part that used to require a backend, and no longer does.

A static page cannot process form submissions by itself. The relay pattern solves it: instead of posting to a server you run, the form sends its fields to a relay endpoint, and the relay emails the submission to you. Every signup lands in your inbox with the fields the visitor filled in.

On VibeDeploy the relay is built into the hosting and included on every plan, the trial too. You switch it on through your AI. With VibeDeploy connected over MCP, ask it to "turn on the forms relay for this site and send submissions to me@example.com". It calls set_forms_config, gets back the endpoint for your site, and updates the page so the form sends its fields there as JSON, with a few lines of JavaScript it writes for you. There is no dashboard screen for the relay yet, so this step needs an MCP client: Claude, Claude Code, Cursor, Codex, or ChatGPT on a plan that allows custom MCP servers to write. The MCP setup page has the steps for each.

What you get: up to five recipients, an optional confirmation email to the visitor, and a reply-to address set to the visitor's email, so you can answer straight from your inbox. Basic spam protection is built in: a hidden honeypot field that bots fill in and people do not, a limit of 10 submissions per visitor IP address every 10 minutes, and a check that submissions come from your own site's domains. No backend, no database, no Mailchimp, no third-party form widget injecting its own branding, and no separate service to sign up for.

For a validation page this is precisely the right amount of machinery. You are expecting dozens of signups, not millions, and an inbox is a perfectly good database at that scale. You can read every signup, reply personally to the interesting ones, and count them without dashboards.

Your own domain beats a builder subdomain

A validation page lives or dies on trust, and the URL is part of the pitch. yourproduct.com reads as a real project. A builder subdomain reads as a weekend experiment.

Buy a domain at any registrar, add it to the site in the dashboard (or ask your AI to), and publish the DNS records you are shown: a TXT record that proves the domain is yours, and a CNAME or A record that points it at VibeDeploy. The certificate is issued automatically once DNS points at VibeDeploy. Your deploy is reachable on a *.vibedeploy.be address immediately, so the domain can propagate while you write your launch posts. When someone asks what you are building, you answer with a domain, not with an apology.

Iterate without fear of breaking it

Validation pages change daily, because the first headline is never the right one. Every deploy is kept as a version with a restore point taken before it, so if the new copy performs worse, you restore the previous version with one click in the site's History tab instead of reconstructing it. On the trial, Solo and Maker the restore window is 3 days.

Staging environments, where you preview a rewrite before it replaces the live page, start at the Studio plan. A one-page validation experiment rarely needs one: make the change, look at the live page right after the deploy, and restore if it looks wrong.

The rhythm becomes: ask the AI for a change, redeploy, check the page, keep it or restore. Minutes per iteration, and no fear of breaking the page that people are actively visiting.

What this costs during the trial

Nothing. The 14-day trial needs no credit card and covers everything this post describes: hosting, one custom domain you already own, SSL, the forms relay and restore points. Two weeks is longer than a validation cycle should take, so the experiment itself is free. If the idea shows signs of life, Solo keeps the page online for EUR 4 per month, flat, and prices include VAT where it applies. Details on the pricing page.