Should You Build a Waitlist Before You Have a Product?

A waitlist can show that people noticed your idea. It cannot show, by itself, that they need it badly enough to use, pay for, or recommend it.

Consider Maya, who wants to build a scheduling tool for independent music teachers. She collects 400 email addresses and feels ready to build for six months. Then launch day arrives. Fewer than ten people open the announcement, three try the product, and nobody schedules a paid setup call.

The waitlist did not fail. Maya asked it to answer the wrong question. A prelaunch list is useful when it starts a conversation and creates a next action. It is weak evidence when it is only a counter.

What does a waitlist actually tell you?

The first signal is attention. Someone understood enough of the promise to submit an address. That can help you identify language that earns a response and audiences worth contacting. Stripe's guide to starting a business from an idea includes a prelaunch page, preorder, or waitlist as a way to gauge interest before committing to a full product.

Attention has limits. The address does not tell Maya which job the teacher needs done, how often the problem occurs, or whether the teacher will change behavior.

Maya should treat each signup as permission to learn more, not as a customer. Her confirmation email can ask what the teacher uses today, when the problem last caused trouble, and whether they would take a 15-minute call. A reply is stronger evidence because it costs more attention and gives her context.

Ask for a harder next step

The page should make one specific promise to one narrow customer group. “Scheduling for music teachers” gives Maya a starting point. “Fill last-minute lesson cancellations without texting every student” gives a teacher something concrete to accept or reject.

After someone joins, offer one next step: a short interview, a manual service, or a paid design-partner session. If Maya is unsure whether the problem is real, she should talk. If she understands the workflow and needs to test value, she should deliver a small version by hand.

The GOV.UK user-research guidance recommends learning who users are, what they are trying to do, how they do it now, and where the problems occur. That is the work a waitlist should make easier, not replace.

Maya can compare signups by source, but she should also record replies, completed calls, trial use, and launch-notification requests. Those events reveal whether the list contains a reachable customer group or low-cost curiosity.

Do not turn the list into a promise you cannot keep

A waitlist is safest when the product, timing, and data use are described honestly. Maya should say what she is testing, what people will receive, and whether joining guarantees access. She should not imply that a launch date is fixed while she is still deciding what to build.

If she asks people to pay before delivery, the decision changes. A preorder creates a real obligation: the Federal Trade Commission's online-order guidance says sellers must ship within the promised time or provide required delay and refund options. A free waitlist avoids that payment obligation, but it does not excuse misleading claims.

Decide what evidence earns the build

Maya should set the next decision before publishing. For example, she might continue only if five teachers describe the same failure, three try a manual version, and at least one accepts a paid setup or normal pilot. Those thresholds are her learning plan, not a universal benchmark.

The list can guide the next move. Strong replies with no usage may mean the promise is interesting but the workflow is weak. Repeated manual use may justify building the narrowest feature that removes the repeated work. No replies may mean Maya chose the wrong audience, message, or problem.

Before you build a waitlist, write the customer, the problem, the next action, and the evidence that would change your plan. Run the page for one week, contact the people who join, and judge the behavior after the signup. If you want peers to pressure-test the experiment, bring it to the buildpurdue cohort.