App Waitlist Form Template
A pre-launch list for your mobile app that sorts iPhone from Android on arrival and asks what day one absolutely must nail.
The app is real, the store listing is coming, and this list gets the download link first. Twenty seconds of questions so launch day fits your phone, not ours.
An app waitlist has an operational wrinkle no web product deals with: two stores, two review clocks, two distribution tracks. A list that doesn't know who carries which phone is just an email pile — on launch day you'll send everyone a landing page and make them fork themselves. This template does the fork at signup, and adds the two questions that make the wait useful: what day one must nail, and who volunteers for the rough builds.
Why these fields. The phone question is launch operations in one tap. iPhone signups can flow toward your TestFlight pool and get the App Store link on day one; Android signups map to the Play internal track and the Play link; the "both" people are your cross-device sync testers, worth their weight in bug reports. The day-one priorities question is deliberately a pick-up-to-two — unlimited checkboxes produce a list where everything matters and nothing ranks, while the constraint forces the trade-off that makes the aggregate readable. If offline mode wins your list by double, your pre-launch sprint just found its priority, and your store screenshots just found their headline. The early-build question separates the crash-tolerant from the launch-day crowd honestly, with the cost stated in the option itself ("crashes and all") — self-selected testers file better reports than drafted ones.
What we left out. OS-version and device-model interrogations (ask the volunteers after they volunteer — three questions about API levels would halve completions), phone numbers (the link arrives by email; nobody needs a call), and open-ended feature essays, which produce wishlists when what you need before launch is a ranking.
Who uses this. Indie developers building in public with a store date on the horizon, startups whose site is one screenshot and a promise, studios porting a web product to mobile, and side projects that want to launch to a warm hundred instead of a cold zero.
Make it yours. The hidden src field takes whatever your share links carry — ?src=qr on the poster, ?src=bio on your profile link, ?src=site on the landing page — so the responses view shows which surface actually fills the list. Set the theme to your app's accent, font, and corner radius; for many apps this form is the pre-launch site, and it should look like the product it's promising. Turn on duplicate prevention per device so one excited person is one row, and when launch week comes, filter by phone platform and export two CSVs — one per store — with the early-build volunteers pulled out first.
Launch to a list, not a void. The difference between shipping to silence and shipping to a hundred people who told you what to nail is this form, shared early enough to matter.
Frequently asked questions
How do I split the iPhone and Android lists at launch?
Filter the responses view by the phone answer and export each as CSV — one list per store link. A webhook can also branch on that answer in your own tooling in real time.
Can the form look like my app instead of a generic page?
Yes — set your accent color, background, font, and corner radius in the theme settings. In Focus mode the form reads like a product screen, which suits a pre-launch page.
What stops one excited person signing up five times?
Duplicate prevention in Settings — per device or per IP — turns repeat submissions into a friendly notice, so your launch-day count reflects people, not enthusiasm.
How do early-build volunteers get treated differently?
Their answer arrives with every response, so filter for the test-group choice, export that slice, and invite them to your TestFlight or Play internal track before the public date.