Launch week for an app, planned one day at a time

Put the fixed things down first: the hour you release, and the hours you actually have for launch work around your job. Then give every launch task a length (reply to reviews, 30 minutes; check search rank, 20) and give each day of the week one job. A launch week with one job a day survives a bad day at work. A launch week made of "see how it goes" does not.

Before the week starts

Two things should already be done, because neither can be done in a hurry on release morning.

The build is approved and set to manual release. Approval is not publication. If you leave it on automatic, the app appears whenever the store decides, which may be 3am your time, and the first hours of a launch are the hours you most want to be at a desk. Manual release hands you the hour.

The support page and the privacy policy are live. Apple asks for both URLs before it will take the build, Google Play asks for the privacy policy, and a page that is a placeholder on Monday is a page a reviewer can see. A support page can be plain: what the app does, an email address, a short answer to the two questions you already know people will ask.

Everything else on this list is a week of work with a day job underneath it, so write it as a week, not a pile.

Day 1: release, and tell the people who asked

Release in the morning. Not because mornings sell more, but because the first problems (a broken sign-in on an older OS, a paywall that shows the wrong price, a crash on first launch) arrive in the first hours, and you want to find them while you can still think.

Then tell the people who asked to hear. Not a campaign: the list of people who, at some point, said send it to me when it's out. Friends, a few beta testers, two or three forum threads where you answered questions honestly, the person who replied to your screenshot. Thirty minutes, one message each, written by hand.

Block the rest of the day small: 20 minutes at lunch to check the dashboards, 45 minutes in the evening. Day one tempts you to sit with the numbers for four hours. The numbers on day one tell you almost nothing.

• Release: 15 minutes.
• Tell the list: 30 minutes.
• Two check-ins: 20 and 45 minutes.

Day 2: crashes and the first reviews

Day two is for what broke and what people said.

Open the crash reports first. One crash on first launch costs more than every other bug in the build, because the people who hit it never come back. Read the stack, find out which devices and which OS versions, and write it down. You are not fixing it today.

Then the reviews. Early reviews are few and loud, and most of them are answerable. Reply to them: both stores let you, few developers do, and a short reply to a one-star review about a missing feature sometimes turns into an edit. Keep it to 30 minutes and keep the replies plain. No apology paragraphs, no promises with dates in them.

• Read crash reports: 30 minutes.
• Reply to reviews: 30 minutes.
• Write the bug list: 15 minutes.

Day 3: where the app shows up in search

This is the day the real question arrives: can anyone find this?

Early on, a new app ranks for very few phrases. That is normal and it is not a verdict. What decides which phrases it can rank for at all is the metadata you already submitted: the app name, the subtitle, and the keyword field. In the App Store, those three fields carry most of the weight. If a phrase appears in none of them, the app is mostly not in the running for it yet.

So spend the 20 minutes doing one thing properly: take the five or six phrases you chose when you wrote the listing, search each one in the App Store, and note where the app appears: its position, or nothing. Do it per country, for the countries you care about, because the answer differs and an average hides it. Write the numbers in a file with the date on it. On day seven you want numbers, not an impression.

If you track this with VisualASO, a Mac app from the same maker as SupaTask, its notes on how keyword demand and difficulty are measured explain what each number can and cannot tell you.

• Check rank for each phrase, each country: 20 minutes.
• Write the numbers down: 5 minutes.

Days 4 and 5: fix the worst bug, prepare a small update

Two evenings, one bug. Pick the worst thing from day two (the crash, or whatever stops someone using the app at all) and fix only that. Then prepare a small update around it.

Small is the point. A 1.0.1 with one fix in it goes out this week. A 1.0.1 with one fix and three improvements goes out in three weeks, because the three improvements need testing you do not have evenings for. Ship the fix, keep the list.

Give the two evenings real lengths and stop when they end: 90 minutes on the fix, 60 minutes to build, test on a real device, write the release notes and submit. Release notes say what a user can now do or no longer suffer. Nothing about internals.

• Fix the one bug: 90 minutes.
• Build, test, submit: 60 minutes.

Day 6: a rest block

Put a block on the timeline that says rest, and give it the hours. An empty day in launch week is not a rest day; it is a day you spend refreshing a dashboard that updates once a day.

The work you did on days one to five is still working while you are away from it. Nothing on the list gets better by being watched.

Day 7: read the week, write 1.1

One hour, at the end. Open what you wrote down and read the week as a whole.

What crashed, and is it gone. What the reviews asked for, counting the asks rather than the loudest one. Where each phrase ranked on day three, and what moved. What you believed on day one that turned out to be wrong.

Then write the list for 1.1, and put the listing on that list. Metadata is a release too: if nobody searched for the phrase you built the subtitle around, the subtitle is a candidate for change. If three reviews used a word you never used, that word belongs in the subtitle or the keyword field. On iOS, changes to the name, subtitle and keyword field go out with a version, so they belong in the 1.1 plan and not in a separate panic.

SupaTask holds the timeline half of this: the release hour and your working day as events, and each launch task as a task with a length beside them. It does not hold the bug list or the rank numbers, and it should not: those belong in a file you can read again on day seven.

Where each one belongs

• The release hour as a fixed event, set to manual release, on the morning of a day you can watch.
• Launch tasks as tasks with lengths on the timeline: 30 minutes for reviews, 20 for rank, 90 for the bug.
• One job per day, written before the week starts, so a bad day at work costs one job and not the week.
• Crash reports and rank numbers in a dated file, not in your head.
• The rest block on day six, as a block with hours in it.
• Everything you cannot ship this week on the 1.1 list, including the listing changes.

FAQ

What time should I release the app?

In the morning of a day you can watch, with the build set to manual release so the hour is yours. The first problems arrive in the first hours, and you want to be awake for them.

How long should launch tasks be?

Short and fixed: 30 minutes for replying to reviews, 20 for checking search rank, 90 for the worst bug. Launch work expands to fill an empty evening unless it has a length.

Should I plan a day off during launch week?

Yes, and put it on the timeline as a block, not as a gap. Day six with nothing in it becomes six hours of refreshing the dashboard.