A good app launch is a four-week process, not a day. Two weeks before: store listings submitted, legal documents live, analytics and support set up, a quiet launch to a small group. Launch day: a working product, a team on standby, one message to one audience. Two weeks after: daily fixes, personal replies to feedback, and the first read of the one number that tells you whether it worked. The launch itself should be small. The preparation and the follow-through are what matter.
Launch day gets the attention, and it is the least important part of a launch. What decides whether the launch works is the two weeks before it and the two weeks after. This checklist covers all four, in the order things need to happen, with the items that founders most often discover at the last minute.
Two weeks before: readiness
Technical
- Production environment set up in your company's cloud account, separate from the testing environment.
- Monitoring and error alerting switched on, going to someone who will act on them.
- Backups running and a restore tested once.
- Analytics instrumented for the one number you will measure, and checked with a test event.
- Payment provider account approved for live transactions, which can take days or weeks. Start this early.
- Transactional emails and notifications tested from the production system, checked for spam folder delivery.
- App store builds submitted for review, with at least a week of margin for a rejection cycle. See app store optimisation basics for the listing.
Legal and trust
- Privacy policy and terms of service live and linked from the app and the store listings. Both stores require them.
- Cookie consent where required, and any consents your product needs captured properly at sign-up.
- Company details, contact email and support channel visible in the app.
Support and operations
- A support inbox, with a person who checks it and a target response time for the first month.
- A short set of canned answers for the questions you can predict: how to reset a password, how refunds work, what devices are supported.
- Admin tools tested for the tasks you will actually do: refund a payment, deactivate an account, correct a listing.
Marketing
- The waiting list or audience you built during the build, ready to email.
- A landing page that matches what the app does now, not what it will do next year.
- One launch message, one call to action, one audience. Not a campaign.
One week before: quiet launch
Invite 20 to 50 people from your list, ideally ones who told you they wanted this. Watch them use it. Fix what breaks every day. This is the most valuable week in the whole launch, because problems found now are cheap and problems found in public are not. If the quiet launch reveals something serious, move the public date. Nobody will notice a week's delay. Everyone notices a broken launch.
Launch day
- The team that built the product is available and knows it. Not "reachable", available.
- Send the one message to the one audience. Email the list, post where your users are, tell the people who said they would share.
- Watch the monitoring, the support inbox and the analytics. Reply to everyone personally.
- Do not ship new features today. Fix, do not build.
- Resist the urge to make it big. A launch that reaches five hundred right people beats one that reaches fifty thousand wrong ones.
Two weeks after: follow-through
- Daily: check the one number, the crash reports, the payment failures and the support inbox. Fix in order of user impact.
- Reply to every review, every email, every message. Ask the people who stopped using it why.
- Sort feedback weekly into fix now, next release and later.
- Start planning the second release from what you heard, not from what you planned before launch. Our post on when to build version two covers how.
- Do not judge the launch by downloads. Judge it by whether users complete the core journey and come back. See which metrics to track after launch.
The checklist in one table
| When | Must be true |
|---|---|
| Two weeks before | Production live, monitoring on, backups tested, analytics checked, payments approved, store builds submitted, legal pages live, support inbox staffed, launch message written |
| One week before | Quiet launch to 20 to 50 people, daily fixes, go or move the date |
| Launch day | Team available, one message to one audience, watch and reply, fix not build |
| Two weeks after | Daily checks, every reply personal, feedback sorted weekly, second release planned from evidence |
What founders discover too late
- The payment provider's approval for live transactions takes weeks, and was applied for on launch week.
- Apple rejected the build over a guideline detail, and the launch date was public.
- Emails go to spam because the sending domain was never set up properly.
- Nobody owns the support inbox.
- The analytics were never checked, and the first month's data is missing or wrong.
- The development team's contract ended at delivery, and the first serious bug waits a week.
Every one of these is on the list above. They are discovered late because launch preparation is treated as a day's work rather than a month's.
How 7L runs a launch
Launch is a phase in our delivery plan with its own checklist, owned by the project manager, starting three to four weeks before the public date. The support period begins on launch day, the team stays on, and we read the first numbers with you. If you are approaching a launch and want a second set of eyes on the list, get in touch.
Frequently asked questions
Should I launch on the App Store and Google Play on the same day?
If you have both apps ready and tested, yes, it simplifies the message. If one is ready and the other is not, launch the ready one. Waiting for both costs more than a split launch.
Do I need press coverage for a launch?
No. Press reaches a broad audience once. Your list and the places your users already gather reach the right audience repeatedly. Press is useful later, when the product has a story and numbers.
What if the quiet launch goes badly?
Then it did its job. Fix what it found and move the public date. A quiet launch exists to make the public one succeed, and a week's delay is invisible to everyone but you.
How long should the development team stay on after launch?
At least six weeks with defined response times, then a retainer or a scoped second release. The first serious bug always appears after launch, and the second release should ship within about six weeks.
Is a product launch platform or a launch event worth it?
Occasionally, for products with broad consumer appeal and a compelling demo. For most first releases, the effort is better spent reaching the specific people the product is for.