Launching Page" Means Something Different: Build a Waitlist Page With Claude and Put It Live Today

Search "launching page" and you'll get two completely different sets of results. Half of them mean landing pages for paid traffic — a topic this blog has covered plenty, including how many distinct pages a campaign actually needs and what breaks when Claude builds them instead of a human clicking drag-and-drop. The other half mean something simpler and more urgent: a coming-soon page. A waitlist. An email capture box sitting on your domain while the real product, the real site, the real business is still being built.

That second meaning is the one almost nobody writes for properly. Every pre-launch guide either pushes a hosted waitlist tool with a monthly subscription and a URL you don't own, or assumes you have a developer sitting idle. Neither fits if you're building with AI and want the page live today, on your own domain, for roughly zero dollars.

Here's the path: Claude writes the page, a form service catches the emails, a free static host puts it on your domain. All three steps fit in an afternoon.

Why a Waitlist Page Is the Perfect First AI Build

If you're new to building websites with AI, a coming-soon page is the ideal first project, and it's worth being deliberate about that instead of starting with your full site.

It's tiny. One screen, one headline, one form, maybe a countdown. There's almost no surface area for an LLM to get something structurally wrong, unlike a multi-page site where navigation, routing, and content architecture create real failure modes. And it's disposable in a good way — whatever you build today is scaffolding, not a foundation. You're not going to feel bad throwing it out when the real site arrives.

It also teaches you the whole stack: code in a chat window, a deploy, a domain pointed at it, a form that actually collects data. Run that loop once on a one-page site and you'll know exactly how to run it on a ten-page site later. If your end goal is to create a blog with AI in an afternoon, the waitlist page is a rehearsal with low stakes.

Step 1: Have Claude Write the Page

Open Claude and describe what you want plainly. You don't need to ask for code jargon. A prompt like:

Build me a single-page coming-soon site for [product]. 
Requirements:
- One headline, one subheadline explaining what's coming
- An email signup form with a visible field and a button
- A short "what we're building" paragraph
- Mobile-friendly, clean, modern design
- Plain HTML/CSS/JS in a single file if possible, or one HTML 
  file plus a stylesheet
- When the form is submitted, POST to this endpoint: [form endpoint]

Two things matter in that prompt more than the design ask.

First, the single-file constraint. A static host doesn't care whether your page is one file or twenty, but you will care when you're copying files out of a chat window. One HTML file with inline CSS and a small script block is the easiest thing in the world to deploy. Ask for it.

Second, the form endpoint — which is the part most AI-built pages get wrong, so let's handle it properly.

Step 2: The Form Is the Only Part That Needs an Outside Service

This is the trap. Claude will happily write you a <form> with a mailto: action or a backend call to a server that doesn't exist. A static page has no server, so a plain form submission goes nowhere. We've covered the full picture of why the default form handler breaks on static hosts and how to route leads into a CRM — for a waitlist page, here's the short version.

You need a form backend: a hosted service that gives you an endpoint URL, receives the POST from your form, and collects the emails for you. The common names here are Formspree, Getform, Basin, and Netlify Forms (which only works if you host on Netlify, more on that in a second). You create an account, get a URL like https://formspree.io/f/yourformid, and paste it into the prompt above. When someone submits, the service emails you or shows submissions in a dashboard.

That's it. For a pre-launch page where you expect dozens or hundreds of signups, the free tiers of these services are more than enough. If you expect thousands before launch, check the submission caps on the free tier before you pick one — the numbers vary by provider and change often enough that you should verify on their pricing page rather than take my word for it.

Step 3: Deploy It Free, Today

You have one HTML file and a form endpoint. Now the hosting question, and this is where "easy hosting solutions" earns its name. What easy means here is: can I get a file folder onto the internet in under ten minutes, without touching a terminal, and with a free tier that doesn't expire?

Three options do this well, and they're the same ones that score well when you judge hosts by what matters for AI-generated code:

• Netlify — drag and drop your file folder onto their dashboard and it's live at a temporary URL in seconds. Bonus: their built-in Netlify Forms can replace the third-party form service entirely; you just add an attribute to your form tag and submissions appear in your dashboard.
• Vercel — same idea, drag-and-drop or Git-based, generous free tier.
• Cloudflare Pages — connects to GitHub or uploads directly, and as a bonus gives you fast global performance for free.

For the absolute fastest path, drag-and-drop on Netlify with no account complexity is hard to beat: folder onto the page, live URL, done.

Step 4: Your Own Domain, Because the Temp URL Isn't the Brand

The yoursite.netlify.app URL is fine for testing and terrible for a launch. You want yourproduct.com on the coming-soon page from day one, because the whole point of a pre-launch page is that people bookmark it, share it, and type it from memory.

Buy the domain at any registrar — Namecheap, Cloudflare, Porkbun are the usual recommendations — then point it at your host by adding the DNS records the host gives you in its custom domain settings. Every host listed above has a settings page that walks you through it; it's typically adding a CNAME record and waiting for DNS to propagate, which can take minutes to a few hours. If you're still choosing a registrar, we've written about alternative domain hosting filtered for AI-built sites, and the same criteria apply here: the registrar is just where the name lives, the host is where the page lives, and you connect them with DNS.

One important note: you don't need "AI domain hosting" as a product category. No such thing exists — a domain is a domain. What matters is that your host handles AI-generated files gracefully, which is the five-feature checklist we laid out in why AI domain hosting is a feature set, not a host.

Step 5: Make It Do One Job Well

A waitlist page has exactly one conversion: an email address. Before you ship, make Claude tighten it:

• One promise in the headline. Not clever — clear. "Private chef booking, launching in Boston this fall" beats "The future of dining."
• A reason to sign up. Early access, launch discount, founding-member pricing. Blank "join our newsletter" converts terribly.
• A fallback for the form. Ask Claude to add a success message and an error state so people know the submission worked.
• A share nudge after signup. A "know someone who'd want this?" line on the success state costs nothing and occasionally doubles your reach.

Run one revision pass in the same chat — "make the headline more specific, add a success message after form submit" — and copy the final file out.

What This Buys You Later

The loop you just ran — prompt to Claude, form endpoint, static deploy, custom domain — is the same loop for everything else on this blog. When the real site exists, this page doesn't get thrown away so much as evolved: swap the waitlist form for real signup, add the pages Claude builds next, and you're no longer pre-launch. And if you want the page to keep improving itself after launch — copy swaps driven by what visitors actually do — that's the subject of wiring your live site to Claude with MCPs and automations.

But that's next month's problem. Today's problem was: you typed "launching page," you had nothing on your domain, and now you have a waitlist collecting emails before dinner. That's the whole job of a pre-launch page, and it turns out it's a one-afternoon job when the page builds itself.