A launch week plan for a small product, day by day

Most small launches don't fail on launch day. They fail in the week before, when the technical work gets left for the last evening, and in the week after, when nobody talks to the people who signed up. This plan spreads the work so the last two days are only about people.

It assumes you have a working first version, a list of people who asked to hear about it, and a date. If you don't have the list yet, start with a one-page test: launching to nobody is the most common way a launch fails.

Seven days out: limits and upgrades

Why now: upgrades take minutes, but finding out you need one takes a problem. A week gives you time to find problems on purpose.

• Count launch-day emails. Invitations × the emails each new user triggers. A common free email plan allows 100 a day^[1]; if you're near it, upgrade now. The working is in Free tiers that break on launch day.
• Move off any plan that pauses or excludes commercial use. Some free databases pause after a week of inactivity^[3]; some hosts pause sites when the monthly allowance runs out^[2].
• Turn on usage alerts at 50% and 80% wherever your tools offer them, sent to an inbox you check.
• Write down your rollback. If a deploy breaks sign-up on launch day, how do you go back to the last working version? Know the button before you need it.

Six days out: email that arrives

• Send from your own domain with SPF, DKIM and DMARC set up. Follow the one-evening fix.
• Send yourself every email the product sends, and read each one on a phone. Fix vague subjects, missing sender names and broken links.
• Check "Show original" in Gmail for each: SPF, DKIM and DMARC should all say PASS.

Five days out: a stranger's path

Why: you know where every button is. Your first users don't.

• Sign up from a fresh email address you've never used with the product, on a phone, on mobile data.
• Go from the landing page to the first useful result without using anything you know as the builder.
• Time it. Write down every moment you hesitated or wondered what to do.
• Fix the top three. Leave the rest for after launch.

Four days out: payments

• Make a real payment with your own card, then refund it. Check the receipt email, the name on the card statement and what happens in the product. Note that processing fees aren't returned on refunds^[4], so this test costs you under a dollar.
• Test a failed payment and a cancellation, not just a success.
• Write a one-paragraph refund policy and put it near the price.
• Decide whether you'll offer a launch discount. If you do, give it an end date and say what it is.

Three days out: the words

• Write the launch email to your waitlist: what it does, who it's for, one link. Use the phrases from your interviews.
• Write a short, honest post for the one or two communities where your customers already are. Read each one's rules on self-promotion first.
• Prepare answers to the five questions you heard most in interviews. You'll paste them all day on launch day.

Hypothetical launch email

Two days out: personal invitations

• Message the people you interviewed individually. They gave you their time; they should hear first, and personally.
• Ask two or three of them to try it the day before launch and tell you what breaks.

The day before: quiet

• Fix only what early testers found that blocks sign-up or payment. Nothing else.
• Stop deploying by the evening. Some hosts count every deploy against your usage^[2], and every deploy is a chance to break something.
• Schedule the launch email for the morning in your customers' time zone.
• Sleep. Launch day is long.

Launch day

• Send the email, publish the post, then stay available. Answer every reply and comment within an hour if you can.
• Invite in batches if your email plan is tight: the waitlist in the morning, communities after lunch.
• Keep a running list of every question and complaint. It's your next two weeks of work.

Numbers to watch

The two days after

• Email every new user personally with one question: "What were you hoping this would do?" The answers tell you what to build next, and what to say on your homepage.
• Look at where people stopped. Fix the biggest drop-off before adding anything new.
• Write down your actual costs for the week. You'll want them when you set or change your price; see What card fees really cost.
• Thank your interviewees and early testers personally.

The week on one screen

What usually goes wrong in launch week

• Launching to everyone at once from a new domain on a free email plan.
• Adding a feature on launch day because someone asked for it.
• Going quiet after launch. The first two days of conversations are worth more than the next two months of guessing.
• Measuring only sign-ups. A sign-up who never reaches the first result usually doesn't stay.

Questions

Put the nine days in your calendar now, starting seven days before your launch date. Then work through launch-day limits, because day −7 is the one people skip.