Launch checklist: from waitlist to public in one week

Going from a waitlist to public is a distinct transition with its own failure modes. This checklist covers the week before, the day of, and the week after.

#One week before

Decide on the invite strategy. Will you invite everyone simultaneously or in batches? Batches let you catch issues before they affect everyone. Simultaneous is simpler if you're confident in your infrastructure.

Clean the list. Pull your signups and filter out bounced addresses (email_status = 'bounced'). Sending invites to addresses that bounced your welcome email wastes the slot. A list of 2,000 with 1,800 deliverable is better than a list of 2,000 with unknown deliverability.

Draft the invite email. Different from the welcome email. The welcome email says "you're on the list." The invite email says "your turn is now." Include:

• What they're getting access to (specific, not vague)
• One link to get started
• Any time-limited context ("access link expires in 7 days" if applicable)

Test the onboarding flow. Create a test account and go through the entire flow a new user will experience. Identify anything that breaks or confuses.

Check your server capacity. If you're inviting 1,000 people and they all try to sign in within the first hour, your authentication service and your database need to handle the concurrent load.

#Two days before

Send a teaser to the waitlist. "Access opens Thursday. We'll email you then." Lowers the shock, increases the click rate on the actual invite.

Set up monitoring. Make sure you have error alerting in place. If signups start failing or your API starts erroring, you want to know within minutes, not hours.

Document the rollback plan. If something goes seriously wrong on launch day, what do you do? Close registrations? Redirect to a maintenance page? Having a plan reduces the time-to-decision in a stressful moment.

#Launch day

Send invites in batches. Start with 10-20% of the list. Watch error rates, server metrics, and support volume for an hour before sending the next batch.

Monitor in real time. Watch your logs, your database connection count, and your error tracker. The first hour of a launch surfaces issues you didn't find in testing.

Respond to support quickly. The first day, people have questions. A fast response builds goodwill and surfaces product issues early.

Post publicly. If you're announcing on Hacker News, Product Hunt, Twitter/X, or elsewhere: do it on launch day, not the day before. You want the energy to be concurrent with access.

#One week after

Review the conversion rate. How many waitlist signups converted to active users? A low conversion rate (below 20-30%) usually means a gap between what the waitlist promised and what the product delivered, or too much time between signup and invite.

Survey the first cohort. Ask what was confusing, what was valuable, what's missing. The first batch of users is unusually willing to give feedback.

Close or convert the waitlist. Once you're in public beta or launch, decide: do you keep the waitlist for new users (backlog management), remove it entirely (open signup), or archive it? Keeping an active waitlist when access is instant creates misleading expectations.

Archive your list. Export a copy of the full signup list with positions, emails, and delivery states before you deprovision anything. You may want it for future cohort analysis.

#The most common mistake

Starting to invite people and then pausing for a few days. The users who got invites told their friends. The friends go to sign up and hit a waitlist. The waitlist has no new communication. They leave and don't come back.

Commit to a completion timeline before you start the invite flow.