Host a coming soon or waitlist page
Before the real site exists, you often just need a single page that says what's coming and collects emails. Here's the fastest way to get one live.
Updated 2026-08-30
A coming soon page is usually the very first thing live for a new product, often well before the product itself is anywhere near done. Its job is narrow: explain what's coming, and capture an email so you can tell people when it's ready. That narrow scope means it doesn't need much from hosting either, even though it's easy to overthink at the start of a project.
What a coming soon page is, technically
Almost always a single static page: a headline, a short description, and an email capture form that posts to a third-party service, a mailing list provider, a forms backend, or a simple API endpoint. There's no application logic living on the page itself; the "backend," such as it is, belongs to whatever service is actually handling the email signups behind the scenes.
That means the page itself is static, and can be hosted the same way any static file would be, with no special setup required just because a launch is involved.
Getting it live fast
Build the page first, hand-coded HTML/CSS, or exported from a design or page-building tool, whichever fits how you already work. Wire up the email capture to whatever service is collecting signups; most provide a form action URL or a snippet to embed, and this works the same regardless of where the page ends up hosted.
Then drop the page, or its folder if it has separate assets, onto a browser-based host:

Get your link immediately and start sending traffic to it: social posts, a note in your bio, a "coming soon" listing on a launch site, wherever people are actually going to find it.
Why speed matters here specifically
A coming soon page often exists because you want to start building an audience before the product is ready. Every day it's not live is a day you're not collecting signups. A hosting setup that takes longer than the page itself took to build defeats the entire purpose of putting one up early.
When the real product launches
Swap the coming soon page for the real site by deploying a new version to the same project. Keeping the same link means everyone who already has it, or bookmarked it, or shared it somewhere, lands on the real thing without you needing to announce a new URL.
Frequently asked questions
Do I need a custom domain for a coming soon page? Not necessarily, a subdomain works fine for building early momentum, and you can move to a custom domain closer to or at launch once it's clear the project is moving forward.
What email service should I use for signups? Any form or mailing list provider that gives you an embeddable form or a submission endpoint works, since the page itself doesn't need to know anything about how the emails are stored.
Should the coming soon page and the final product live at the same link? Generally yes, redeploying the same project when the real product is ready means the link people already have or shared keeps working, rather than needing a new URL announced separately.
