You launch an app with a waitlist by publishing a one-promise page with an email form before the store listing exists, using that list to fill a beta, then converting it into store pre-orders or pre-registrations and sending exactly the emails you promised. The store tools set the timing: TestFlight builds expire after 90 days, a Google Play pre-registration campaign can run for at most 90 days, and App Store pre-orders open up to 180 days before release. Plan the sequence around those windows and the list does the rest.
What should the waitlist page promise?
One outcome, in one sentence, for one kind of person. The page exists to collect an address and set an expectation, so everything on it should serve those two jobs. Write the outcome as the user would say it, put the form in the first screen, and say plainly what joining gets them.
State the email contract next to the button. We run two waitlists at qubba.ai/apps, one for StudyOS and one for QScan, and each form says the same thing: one email when the app is ready, nothing else. That line costs nothing and it removes the main reason people hesitate at an email field.
Skip the fake scarcity. A counter you cannot back up, a "spots left" badge, or a launch date you have not confirmed with the store review process all turn into support tickets later. Store badges should say "coming soon" and stay unlinked until the listing is live.
How do you turn a waitlist into a beta?
On iPhone the tool is TestFlight, which is included with the Apple Developer Program at 99 US dollars a year. TestFlight supports up to 100 internal testers who hold roles in your App Store Connect team and up to 10,000 external testers, on up to 30 devices each, and public links let you invite people without collecting their contact details. You can set device and OS criteria on a public link, see how many people viewed it, installed, and met or missed the criteria, and disable the link when the group is full.
Two constraints shape the calendar. Per Apple's TestFlight overview, builds become unavailable to testers after 90 days, and the first build you add to an external group is sent to App Review before anyone outside your team can install it. Submit that first external build well before you email the list, or your "beta is open" message will arrive before the build does.
On Android the gate is different. Google Play charges a one-time 25 US dollar registration fee and may ask for a government ID and a card under your legal name. For personal accounts created after 13 November 2023, production access requires a closed test with at least 12 testers opted in continuously for 14 consecutive days, followed by an application that Google typically reviews within seven days. A waitlist of a few hundred people is exactly how you find 12 testers who will stay opted in for two weeks.
Pick beta testers from the list by asking one question at signup: which device do you use? That single field lets you invite the right people to the right store and avoids emailing an Android user a TestFlight link.
Should you use App Store pre-orders or Play pre-registration?
Both let people commit before launch and both install the app automatically on release day, which turns a waitlist into installs without a second email. The rules differ enough that you should read them before you set a date.
| App Store pre-orders | Google Play pre-registration | |
|---|---|---|
| How early | 2 to 180 days before release for a new app; 2 to 365 days when bringing an existing app to new regions | Campaign lasts at most 90 days, then you must launch |
| On release day | App downloads automatically to devices that pre-ordered, with a notification | Push notification to every pre-registered user; auto install on eligible devices |
| Regions | Configurable per region with different release dates | Chosen per country; missing the deadline in any country ends the campaign in all of them |
| Extras | A receipt field lets you identify pre-order customers in the app | You can give a one-time in-app product free to pre-registered users |
| Limits | Requires iOS 11.2 or later | Up to two apps in pre-registration at once |
Sources: Apple's pre-order documentation and Google's pre-registration help. Two details from Google's page matter for planning. Auto install only applies below 2 GB, and apps above 200 MB install only over Wi-Fi. And if you have not launched within 90 days, the campaign is terminated in all countries and you cannot start a new one, so open pre-registration only once the build is close to final.
The practical order is: waitlist first, beta from the waitlist, pre-order or pre-registration once the release build is submitted, launch email on the day.
What emails are you allowed to send?
Fewer than you would like, and they must follow rules. In the United States the CAN-SPAM Act requires accurate From, To and routing information, a subject line that reflects the content, a clear identification of the message as an ad, your valid physical postal address, a clear and conspicuous way to opt out, and that you honor opt-outs within 10 business days. Each separate email in violation can carry a penalty of up to 53,088 US dollars, and hiring a vendor does not transfer the responsibility.
Other jurisdictions have their own regimes, and the safest baseline everywhere is the same: explicit opt-in at signup, an unsubscribe link that works on the first click, and no messages you did not promise. If your form said one email at launch, send one email at launch.
Keep the launch email short: what shipped, the store link, and how to reach a human. Reply-to should be a monitored inbox, because launch day replies are the best user research you will get.
What should launch day look like?
Release the build so pre-orders download and pre-registration notifications fire, then send the one email. Do this on a weekday morning in your main market so you can answer replies and watch for crashes while people are awake.
Enroll in the App Store Small Business Program before revenue starts. Developers new to the App Store, or who earned up to 1 million US dollars in the prior calendar year across all apps, pay 15% commission instead of the standard rate, and you must declare any associated developer accounts.
Measure the funnel you built rather than vanity numbers: signups to beta invites, invites to installs (TestFlight shows view and install counts per public link), pre-orders to launch day installs, and launch email to store visits. Those four ratios tell you where the next launch leaks.
Frequently asked questions
How long before launch should you open a waitlist?
Open it as soon as you can state the promise in one sentence, because the list feeds every later step: beta testers, pre-orders and the launch email.
The store windows set the back end.
TestFlight builds expire after 90 days, Play pre-registration lasts at most 90 days, and App Store pre-orders can open up to 180 days ahead.
Do you need a waitlist if the store offers pre-orders?
Pre-orders and pre-registration only exist once you have a store listing and a near-final build, and a Play campaign ends if you miss its 90-day deadline.
A waitlist works months earlier, costs one form, and gives you beta testers for TestFlight and the 12 opted-in testers a new Play account needs before production access.
What is the minimum a launch email must contain?
Under CAN-SPAM: accurate header information, a truthful subject line, identification as an advertisement, your valid physical postal address, and a clear opt-out method that you honor within 10 business days.
Add the store link and a monitored reply address.
If you promised one email, this is the one.
Should StudyOS-style waitlists collect more than an email?
Collect the device platform and nothing else you will not use.
Platform lets you route iPhone signups to TestFlight and Android signups to a closed test, which is the one piece of data that changes what you send.
Every extra field lowers signups and adds a promise about data you now have to keep.