Plan an app launch like a project: four milestones, one owner per task, and the launch-week list

An app launch is a project: a date, a fixed scope, two or three people, and a finish line in a review queue you do not control. Set the release date first. Walk back from it in four milestones. Put one owner on every task. Treat the store listing as its own workstream rather than a chore at the end. Then run a launch-week list. That is the whole method.

Set the release date, then walk back in four milestones

Write the release date at the bottom of the page and work upwards. Four milestones fit almost every launch, and the gaps between them are the slack you will need.

Say you want to be live on Tuesday 1 December.

Build frozen, 10 November. Feature work stops. Whatever is not in by that date ships in 1.1 instead. Write the cut list down, because an undocumented cut comes back as "quick, while we wait for review".

Store listing ready, 17 November. Name, subtitle, keyword field, description, screenshots, privacy details and the Play data safety form, age rating. All of it, both stores, finished and reviewed.

Submitted and passed, 24 November. Submit on the 18th. The week of slack is not padding; it is there for one rejection. On Google Play, a new personal developer account cannot publish to production until a closed test has run with at least 12 testers for 14 days, so if that is you, start the test before the build freeze.

Release and launch week, 1 December. The build sits approved with manual release on, and you press the button.

Four dates, three gaps. The build freeze to listing gap is where you stop writing code and start writing words, and most solo developers are bad at it, which is why it gets its own week.

One owner per task

A task with two owners is a task nobody does. Put a single name on each one, including the dull ones.

Lina takes the build: version numbers, the signing certificate, the release keystore kept somewhere she can find it again in a year, the TestFlight build, the final archive. Tom takes the listing and the pages: the app name and subtitle, the screenshots, the privacy policy and support pages on the domain, the two store forms. Whoever is slower at writing takes the description, because it always takes longer than they think.

If you are launching alone, the method still holds. One owner per task becomes one day per task, and the value of the list is that you stop holding fourteen half-finished things in your head.

The store listing is its own workstream

Here is the part indie developers underrate. Many of the people who will install your app are not clicking a link from you. They are in the App Store, typing two or three words into the search box, and tapping something in the first few results. Your listing is not a formality for the reviewer. It is the thing that decides whether you are in those results at all.

On iOS, Apple reads three fields for search: the app name, the subtitle, and the keyword field. The keyword field is 100 characters, comma separated, invisible to users. Do not repeat words that already appear in the name or subtitle, because they are indexed anyway and you only have 100 characters to spend. Fill it with the words people type, commas and no spaces, and pick the phrases behind them on two tests at once: do people search for this, and can a brand-new app rank for it? "Habit tracker" fails the second test. "Shared shopping list for flatmates" might pass both.

Google Play reads the title, short description and full description, so write the full description for a reader who is scanning, with your main phrases in the first two lines.

Then check what happened. After release, your rank for each phrase is a number, and it differs by country. If you want numbers rather than guesses, VisualASO, a Mac app from the same maker as Blueprint, checks where your app ranks for each phrase, country by country, how many people search for it, and how hard the top ten is to reach. Either way, the task on the board is the same: pick ten phrases before you submit, record where you land after release, and change the fields in the next version based on what you see.

The budget lines

An app launch has fewer costs than a house move and they are easy to list, so list them and stop wondering.

• Apple Developer Program: 99 US dollars a year. Recurring, so put it in the plan as a yearly line, not a one-off.
• Google Play developer registration: 25 US dollars, paid once.
• A domain. Both stores require a URL for support and a URL for your privacy policy, which means you need somewhere to put two plain pages before you submit.
• Design. An icon, and screenshots that are composed rather than captured. This is the line that varies from zero to several hundred, and it is the one worth money if you have any.

Put each against the milestone it blocks. The domain blocks "listing ready", not "release". The developer accounts block submission, and Apple's account verification is not instant, so open them during the build, not the week you submit.

The launch-week list

Keep it short enough to read on the day.

• Confirm the build is approved and set to manual release on both stores.
• Check the support URL and privacy policy pages are live and load on a phone.
• Tell the people who asked to hear about it, individually, in the order they asked.
• Reply to the first reviews. Early reviews are read closely by the next person who finds you.
• Check search rank on day 3 and day 7, in your main countries.
• Write down what to change in the next version while the irritation is fresh.

The launch ends, running the app does not

The project finishes when the app is live and the launch-week list is done. Close it. What follows is a different project with a different shape: updates, replies to reviews, bugs found by people who are not you, and the listing revisited every few releases as you learn which phrases actually bring installs.

In Blueprint that is two projects on the board. "Launch 1.0" has an end date and four milestones and gets archived. "Run the app" is the one that stays open. Track time against both and you learn something you cannot get any other way: what a launch cost you in hours, and how much of each week the live app takes back.

FAQ

How long should I allow for App Store review?

App Store review often takes a day or two, but it can bounce for a missing privacy answer or a login the reviewer cannot get past. Leave a week between submitting and your release date so one rejection does not move the date. Google Play review can also take several days, and a new personal developer account must first run a closed test with at least 12 testers for 14 days before it can publish to production.

What does it cost to launch an app on both stores?

The Apple Developer Program is 99 US dollars a year and Google Play charges a one-time 25 US dollar registration. On top of that you need a domain, because both stores ask for a support URL and a privacy policy URL. Design is the line that varies most, from nothing if you draw it yourself to a few hundred for an icon and screenshots.

What should go in the keyword field?

The iOS keyword field holds 100 characters, comma separated, and nobody sees it. Do not spend characters on words already in your app name or subtitle, because Apple reads those fields too. Fill it with phrases people actually type and that a new app can realistically rank for.