App Launch Checklist: The Last 7 Days Before You Ship

You have a launch date, or you have a rough one. Either way, the last week decides whether the day is a launch or a quiet upload.

Most checklists for this are written for teams: press kits, partner outreach, a launch event. If you are one person who built the app, most of that is noise. What follows is the shorter list. It is ordered by what is hardest to fix once the day starts.

We are using it ourselves. Kwern opens to the public on Monday 19 October, so this week we are working through the same seven steps, and we have not ticked every box. Where that matters, we say so.

Day 7: read your own listing as a stranger

Open your store listing on a phone, signed out, and give it ten seconds. Then answer three questions.

• Can you say what the app does from the first screenshot alone? Most people never scroll past it. If the first image is a logo or a splash screen, replace it with the screen that shows the result.
• Do the first two lines of the description say who it is for? On the App Store the description is not what ranks you, but it is what a visitor reads before deciding.
• Is anything stale? Old pricing, a feature you removed, a screenshot of a design you changed in August.

Fix what you can today, because App Store text changes outside the promotional text field go through review. The promotional text field is the exception: it can change without a new version, so keep a launch line ready for it. On Google Play, the short description holds 80 characters, so write it like a headline.

Check the keyword field while you are there. On the App Store it holds 100 characters. Do not repeat words already in your title and subtitle, and do not spend space on plurals you do not need.

Day 6: write down your baseline

Makers skip this step, and you cannot do it afterwards.

Open App Store Connect or Play Console and note, in a plain file, today's figures for:

• impressions (or store listing visitors on Play)
• product page views
• first-time downloads
• conversion rate from page view to download
• current rating and number of ratings

Add your website's weekly sessions from your analytics if you have a site.

The reason is simple. After launch you will have a number and no idea whether it is good. A baseline turns "100K views and 35 downloads" from a feeling into a question you can answer: did people fail to find the listing, or did they find it and leave? Impressions and page views tell you the first. Conversion rate tells you the second. They need different fixes, and the console reports are free.

Day 5: tell the waitlist the date, and give them one job

If you have a waitlist, it has been cooling since the day people signed up. A long silence followed by "we are live" reads as a stranger's email.

Send one message this week. It needs three things:

1. The date, stated plainly. If the date might move, say what it depends on and when you will confirm.
2. One thing to do on the day. Download it, or rate it, or reply with what they want most. Not three things.
3. A reason to act early. Something true. An early-access note, a say in the first update, a direct line to you. Do not invent scarcity.

If your launch could slip by a week or two, send a short note anyway. "Still on track, here is what changed" keeps a list warm better than silence does. Waitlists rarely convert in full. Treat the ones who reply as your first real conversations.

We have a small early-access list ourselves, and the same message is going to it: the date, one action, nothing else.

Day 4: prepare the replies before you need them

Launch day produces questions faster than you can think. Write the answers now.

Make a short file with:

• your answer to "how is this different from X?" in two sentences, including where X is the better choice
• your answer to "what does it cost?" with the actual price
• your answer to "is my data safe?" with what you store and where
• a one-line reply for a first five-star review, and a calm reply for a first one-star review

On the App Store you can reply to reviews as the developer, and replies show under the review. Keep them short and specific. Thank the person for the detail they gave, say what you will do, and do not argue. A one-star review with a good reply reads as a point in your favour to the next visitor.

None of this needs to be clever. It needs to exist before launch morning.

Day 3: choose one channel for the day and prepare the posts

You cannot work six channels at once on the day. Pick the one where your users already are, and prepare the rest as a short list you can post in ten minutes each.

For most indie apps the shortlist looks like this:

• Your own social account: one post that shows the result rather than describing the app. A short screen recording beats a paragraph.
• One community where you are already a member. Read its rules first. Many subreddits forbid launch posts from accounts that only appear to promote. If you have never commented there, answer questions for a few weeks first, and do not drop a launch post in cold.
• Your waitlist, as above.

Write the posts now and schedule nothing you cannot read again on the day. Post by hand where the platform expects a person, and plan to be around for the first three hours to answer comments. A post you cannot reply under is worth much less than one you can.

We have one gap here and will not hide it: the screen recording of our approval feed is still on the maker's to-do list. If yours is not done by day 3, post a screenshot and say a recording is coming.

Day 2: test the path from post to install

Do this on a real phone, on mobile data, not on your development Wi-Fi.

• Tap the link in each post you are about to publish. Does it land on the store page, in the right country, with the right language?
• If you use a short link or a campaign link, check that it still opens the store page when the app is not installed.
• Install the production build from the store (or TestFlight if you are not live yet) and run through first launch. Look for the thing you would blame the user for: a permission prompt at the wrong moment, a paywall before any value, a sign-up wall.

If the first minute is bad, no amount of posting helps. Fix the first minute before you fix anything else on this list.

Day 1: set the quiet parts

The small things that make launch day less stressful:

• Add a support email to the listing and check that it reaches you.
• Make sure your privacy policy page loads and says what the app really collects.
• Turn on store notifications for new reviews, so you see them within the hour.
• Clear your calendar for the first three hours. Tell whoever needs to know.
• Eat something.

Launch day: a short run sheet

Keep the day small.

1. Publish the store change or release at the time you planned. Check the store page loads.
2. Post to your chosen channel. Put the link in the first reply if the platform buries links in the post body.
3. Send the waitlist message.
4. For three hours, answer every question. Quote numbers and prices as written, never as remembered.
5. Late in the day, write down what people asked and objected to, in their words. That list is better product research than anything you can run this month.

The week after: read the console, then decide

Do not judge the launch from your feelings or from vanity numbers. Open the same console reports you saved on day 6 and compare:

• If impressions rose and conversion held, the launch worked on awareness. Look at which source sent the traffic and do more of it.
• If impressions rose and conversion fell, the audience was wrong or the listing is not telling the story. Change the first screenshot and the first two lines of the description, and give it a week.
• If impressions barely moved, people did not see you. The fix is distribution, not the listing. Pick another channel and repeat.

Change one thing at a time and give each change a week. If you change five things on day two, you will not know which one worked.

Where Kwern fits, briefly

This list is manual, and you can run all of it with a notes app and the store consoles. If you would rather not do it by hand, Kwern's agents do the listing audit, the review replies and the weekly console read as drafts you approve. Every action waits for your yes. The agents work from your product's real data, read through its connectors, and the model runs on your own provider key.

If you read this and decide the notes app is enough, that is a fine answer. The checklist matters more than the tool.

The checklist on one screen

• Day 7: read the listing as a stranger, fix stale text, check the keyword field
• Day 6: write down the baseline from the store console
• Day 5: tell the waitlist the date and give them one job
• Day 4: write the replies you will need
• Day 3: pick one channel, prepare the posts
• Day 2: test the path from post to install on a real phone
• Day 1: support email, privacy policy, review alerts, a clear calendar
• Launch day: post, answer, write down what people say
• Week after: compare with the baseline, change one thing