Waitlist or Launch Now? How to Decide

The honest answer is conditional, and one question settles most of it: could a stranger use your product today, without you on a call walking them through it? If yes, you do not need a waitlist. Ship it, put it somewhere people can find it, and start collecting the feedback a list would have made you wait for. A waitlist is the right move in one situation: the thing genuinely is not usable yet, the gap is measured in weeks or months rather than "someday", and you already have somewhere to send people so the list will not sit at four names. Everything else is either early access, which is a different mechanic with a different job, or a delay dressed up as a strategy.

Almost everything written about pre-launch waitlists is published by companies that sell waitlist pages, referral widgets, and viral leaderboards. That does not make the advice wrong, but it does explain why the answer is always yes, and why the numbers attached to it are so cheerful. You will see conversion figures quoted confidently: a waitlist converts at 10 to 20 percent, a good landing page hits 25 to 45 percent, personalised outreach lands at 15 to 30 percent. Ask where any of those came from and the trail goes cold. There is no public dataset behind them. Treat a number with no source as a mood, not a benchmark.

Here is the version written by someone who runs a showcase where the whole point is people actually trying things, and who therefore has an obvious bias in the other direction. I will flag that bias where it matters.

What is a waitlist actually for?

A waitlist does three things, and only three. It is worth being precise, because two of them get confused with a fourth thing that a waitlist does not do at all.

It reserves permission to contact people later. That is the real asset. Someone typed their email address into a box, which means you can send them a message in six weeks without it being cold outreach. Permission is genuinely valuable and genuinely hard to get.

It gives you a rough read on whether the pitch lands. Not whether the product works. Whether the sentence works. If a hundred people read your one-paragraph description and none of them want to be told when it ships, the description is wrong, or the problem is not painful, or you found the wrong hundred people. That is a useful signal and it costs almost nothing to collect.

It creates a launch day that is not a standing start. Instead of shipping into silence, you ship into an inbox of people who asked to hear from you. For a product where day one traffic actually matters, like a paid launch or a platform launch with a ranking attached, that is a real advantage.

What a waitlist does not do is validate the product. A signup is a person saying "this description sounds relevant to me" at zero cost and zero commitment. It is not a person saying "I will change how I work". People who have never touched your product cannot tell you whether it is any good, and a list of them, however long, will not tell you either. That distinction is the whole argument, and the rest of this post is what follows from it.

When does a waitlist cost you more than it earns?

Three costs, all of them invisible at the moment you decide.

It buys time at the price of feedback. This is the expensive one. Every week the thing sits behind a signup form is a week nobody has used it, which means a week you cannot learn that onboarding loses people at step two, or that the feature you spent nine days on gets ignored. Feedback you get in week one changes what you build. Feedback you get after launch changes what you apologise for. If your product could be in someone's hands on Saturday, a waitlist is a decision to not know anything until knowing is more expensive to act on.

It produces a number that feels like progress. Four hundred signups looks like traction. It looks like a thing you can put in an update, tell a friend about, screenshot. It is not traction, and the gap between the feeling and the reality tends to get discovered on launch day, which is the worst possible moment. Ten people using your app badly will teach you more than four hundred people who signed up and forgot.

It creates an obligation with a shelf life. A list you never email decays into a list of people who will report you as spam when you finally do. That is not a soft claim about attention spans. It is a deliverability mechanic with published thresholds, which I will come back to below.

There is a fourth cost that is harder to name. Building the waitlist page is fun. It is design work, copy work, a referral mechanic to fiddle with, a counter that goes up. It is also, reliably, a way to spend a fortnight not building the product. If you notice yourself picking fonts for the coming soon page, that is worth being honest with yourself about.

Which do you need: a waitlist, early access, or a launch?

Two gates. Answer them in order and you land in one of five places.

Gate one: could a stranger use it today?

The test is literal. You send the URL to someone who has never seen the product, you do not get on a call, you do not screen share, you do not fix anything for them while they watch. Can they do the main thing it does and get a result? If you are already composing the caveats you would send with the link, the answer is no.

Note what the gate does not ask. It does not ask whether the product is finished, polished, feature complete, or something you would be proud to show. Almost nothing is, on the day it first works. It asks whether a stranger, alone, gets to the payoff.

Gate two: does anyone already know you are building it?

Meaning: is there anywhere you could send five hundred people from, today. A community you have been part of for a year, a newsletter, a build-in-public thread with replies on it, a group chat of other makers. Not an audience in the influencer sense. Just somewhere that is not zero.

Usable by a stranger today?	Does anyone know you are building it?	What to do	Why
Yes	Yes	Ship it to them today	The list would be a queue in front of a door that is already open.
Yes	No	Launch now, recruit the first ten by hand	Distribution is your problem, and a signup form does not solve distribution.
No, but weeks away	Yes	Early access, invited in cohorts	You have demand and no capacity. That is exactly what early access is for.
No, but weeks away	No	Build in public, collect names as a side effect	The list is the byproduct, not the project.
No, months away or no date	Either	No list yet	You will have nothing to send, and a silent list goes stale.

The only row where a classic waitlist is clearly the right answer is the fourth one, and even there the waitlist is not the work. The work is having something specific to say publicly every week. The email box at the bottom of the page just catches the people who liked what you said.

If you landed in row five, the useful move is to keep a private list instead: names in a text file, people you have spoken to, no email form anywhere. You can write to them individually when there is something to see. That is not a waitlist, it is a memory.

What is the difference between a waitlist and early access?

They get used interchangeably and they are not the same mechanic. The difference is what the gate is made of.

A waitlist is gated by time. The product does not exist yet in a usable form, and everyone waits together until it does. The list is passive. Nobody on it can do anything except wait for your email. The number can grow indefinitely because it costs you nothing to add another row.

Early access is gated by capacity. The product works, you can only support a limited number of people at once, and you let them in a few at a time in whatever order makes sense. The people inside are using it. They can break it, complain about it, and tell you what to fix. The queue is real because your ability to onboard people is real.

The second one is strictly better whenever it is available to you, because it converts waiting into learning. It also carries an honesty requirement. If you are gating on capacity, the capacity limit has to be true. Manufactured scarcity, a queue with nothing behind it, a counter claiming thousands of people ahead of you when the product is a small app on a hosting plan that could serve all of them at once, is a trick that costs you the trust of exactly the people most likely to tell their friends. Builders notice.

A third option sits between them and gets overlooked: ship it publicly, rough edges and all, and let people self select. Put the rough parts in writing on the page. "This does one thing, it does not do these four things yet, here is where it will break." The people who try it anyway are the people you want, and you skipped the queue entirely.

How long can a list stay warm?

Nobody can give you a verified half life, and anyone quoting one is guessing. What is documented is the other end of the problem: what happens to your ability to reach people when you go quiet and then come back.

Mailbox providers judge you on complaint rate. Google's Email sender guidelines ask senders to keep the spam rate reported in Postmaster Tools below 0.10 percent and to never let it reach 0.30 percent. That is a thin tolerance. On a list of a thousand people, a few dozen "who is this?" complaints is enough to change how your mail gets treated, and a launch email to a list that last heard from you five months ago is the most reliable way there is to generate them. The same guidelines require marketing and subscribed messages to carry a clearly visible unsubscribe link in the message body, and to support one-click unsubscribe once you are sending more than 5,000 messages a day.

There is a legal floor underneath that, and solo builders routinely miss it. Under the FTC's CAN-SPAM Act compliance guide, a commercial email must include your valid physical postal address, must give recipients a working way to opt out, must honour an opt-out request within 10 business days, and the opt-out mechanism has to keep working for at least 30 days after the message goes out. Read that first requirement again if you work from home. Deciding where that address comes from is part of the cost of opening a waitlist, and it is a decision worth making before the form goes live rather than the night before your launch email.

The practical version: a list stays warm for as long as you keep talking to it, and no longer. If you cannot commit to writing something every two or three weeks between now and launch, you are not building a waitlist, you are building a liability with an unsubscribe rate attached.

What do you send a waitlist while they wait?

Assume you have decided the waitlist is right. Here is the cadence that keeps it alive without becoming a second job.

The first email goes out immediately, and it asks one question. Not a welcome sequence. One short message that confirms they are on the list, says roughly when they will hear from you next, and asks a single question they can answer in one line: how are you handling this today? The replies to that question are the most valuable thing the entire waitlist will produce. They are free customer interviews from people who raised their hand voluntarily. Read every one, and reply to every one.

Then something every two to three weeks, and each one contains a thing. A screenshot of a screen that now exists. A decision you made and why. A problem you hit and how you got around it. A short clip of the feature working. The test for whether an email is worth sending: does it show or tell them something concrete? "Still working hard, thanks for your patience" fails that test and trains people to stop opening.

Segment by what people told you, not by when they signed up. If forty people answered the first question with variations of the same use case, that is your first cohort for early access, and they should hear about it before the rest of the list.

Say plainly when the date moves. It will move. An email that says "this is six weeks later than I said, here is what took the time" costs you almost nobody and buys a lot of credibility. Silence costs you the list.

Let people leave easily. Every unsubscribe is someone who was going to complain instead. That link is not a leak in the bucket, it is the pressure valve that keeps your complaint rate inside the range described above.

What should you do instead if you can ship today?

If you passed gate one, the waitlist question is closed and the real question is distribution. That is a harder problem, and no signup form solves it.

The move that works, and has worked for a long time, is unglamorous. Paul Graham's essay Do Things that Don't Scale makes the case better than I can: the most common unscalable thing founders have to do at the start is recruit users manually, one at a time, by going to where those people already are. Nearly every startup has to do it, and the ones that skip it because it feels inefficient tend to end up with a beautiful landing page and no users.

Concretely, for a solo builder with something that works today:

1. Make a list of ten named humans who have already described your problem in public. The method for building that list from a blank page, with no network, is in how to get your first 10 users for a side project.
2. Ask each of them differently. Ten separate messages that reference what that specific person wrote. Not a broadcast.
3. Put it somewhere permanent. A launch day is one day. A listing keeps working afterwards, so get it onto the showcase and anywhere else your kind of user browses.
4. Trade attention with other builders. Reciprocal communities like Favors.dev exist so you can swap a real test for a real test instead of collecting passive impressions.
5. Recruit testers deliberately if the thing genuinely needs a beta first. The zero audience version of that is in how to find beta testers with no audience.
6. Watch what happens when people arrive and do nothing. If they land and bounce, the problem is the first screen, not the traffic. Why nobody tries your app is the diagnostic for that.

Here is the bias I promised to flag. I run a directory, so of course my advice trends towards "ship it and list it". Take the self interested part with appropriate salt. The part I would stand behind regardless: a product in front of ten real people beats a list of four hundred strangers, and the gap gets wider the earlier you are.

One practical constraint worth knowing before you plan around it. A waitlist page on its own is generally not listable on app directories, ours included. Our review needs a working URL and an app that is free to try, so a coming soon page with an email box has nothing for a reviewer to open. Come back when it works, and submit it free.

FAQ

How many waitlist signups is a good sign?

There is no threshold, and any specific number you see quoted almost certainly has no data behind it. What matters more than the count is where the signups came from and what they said. Forty people from one community you have been part of for a year, ten of whom replied to your first email describing their current workaround in detail, is a strong position. Four hundred from a referral loop where nobody has told you anything about themselves is a mailing list, not a signal. Judge the list by the quality of the replies you can get out of it, not by the counter.

Do waitlist signups convert to users?

Some do. The honest framing is that conversion depends almost entirely on how much contact there was between signup and launch, and you should be sceptical of the specific rates you see quoted, because they are usually published by companies selling waitlist software and rarely carry a source you can check. A list you wrote to every three weeks with something real in each email will do far better than one that went silent for four months, and a list segmented by what people actually told you will do better than both. Plan around the fact that a meaningful share of any list will not remember signing up.

Can I list a waitlist on directories?

Usually not, and you should check each platform's own policy rather than assume. Most directories that review submissions by hand, including this one, require a working product that a reviewer can open and a visitor can try. A coming soon page fails that test because there is nothing to review. Some launch platforms do run a separate upcoming or coming soon surface built for exactly this case, which is a different thing from their main listing, so read their documentation before planning a pre-launch push around it. The safe sequence is: waitlist page on your own domain during the wait, directory submissions once the thing works.

How long before launch should a waitlist open?

Open it when you can say something specific about what the product does and roughly when it will exist, and not before. In practice that tends to be a matter of weeks rather than many months, because the real constraint is not some optimal window, it is your ability to keep writing to the list. Work backwards instead. Count how many genuinely interesting updates you can send between now and launch at one every two or three weeks. If the answer is fewer than three, you are opening too early. If the answer is zero, keep a private list of names and skip the form entirely.