How to launch an app
What to do in the six weeks around shipping a mobile app, in order — store listing, testers, launch day, and the month that matters more.
The hard part of launching an app is not launch day. It is that most of what decides how the launch goes happened weeks earlier, in the store listing and the first fifty installs, and by the time you are posting about it those are already fixed.
This is the sequence in the order it actually has to happen. It assumes a mobile app; if you are shipping a web product, how to launch a SaaS product is the closer fit.
Six weeks out: the store listing is the product
For an app, the store listing is not marketing collateral. It is the page every single install goes through, it is the only thing the store's own search can read, and it is much harder to change later than you think.
- The title carries the search term. Not just your brand name. "Cadence — habit tracker" is findable; "Cadence" is not, unless somebody already knows the name. You get thirty characters on the App Store and fifty on Play, and the words in there are weighted more heavily than anything else on the page.
- The subtitle and the short description are the second half of that, and they are indexed too.
- The first two screenshots decide the install. People do not swipe. Put the thing the app does in the first frame, with a caption on it, and never lead with an empty state or a sign-up screen.
- The keyword field on the App Store is not the description. It is a hundred-character comma-separated list, it is invisible to users, and it is the one part of the listing that exists purely for search. Do not waste it on words already in your title.
Write the listing before the app is finished. It will change what you build.
Four weeks out: get it into real hands
Fifty real testers is worth more than any launch tactic on this page, because they find the thing that makes people quit on the second screen.
- TestFlight on iOS, an open testing track on Play. Both take a few days to approve the first build, which is the deadline people miss.
- Ask testers one question, not a survey: what were you trying to do when you stopped. Anything else gets you politeness.
- Watch a session recording or sit next to somebody. The gap between what people say and what they do is the whole point of testing.
Play requires a period of closed testing with a minimum number of testers before a personal developer account can publish publicly. The rules have changed more than once and the current numbers are on Google's own page, so check them the week you start rather than trusting a blog post. If they apply to you, that requirement, not your code, is your launch date.
Two weeks out: the things with a queue
- Review takes days and can reject you. Budget for one rejection. The common ones are a sign-in wall with no demo account, a privacy policy URL that 404s, and a data-collection disclosure that does not match what the app does.
- Build the assets once: a square icon, a screenshot set per device size, a thirty-second demo video, one paragraph of description and one sentence. You will paste that set into twenty forms.
- Set up a landing page that is not the store. Somewhere links can point, somewhere search can index, and somewhere people on the wrong device can still read what the app is.
Launch week
The whole plan in one line: post where the people with the problem already are, and be present rather than promotional.
- Show HN and the launch boards. Product Hunt alternatives covers which board suits which product; for an app, the ones with a consumer audience are worth more than the developer-tool boards.
- The communities where the problem lives. A subreddit, a Discord, a forum for the hobby your app serves. Read the rules, and post the thing you learned rather than the thing you are selling.
- Ask for reviews inside the app, at the moment somebody finishes something rather than on open. Ratings are ranking input in both stores, and the first twenty matter disproportionately because that is what a stranger sees.
- Do not buy installs. Retention is what the stores rank on, and bought installs are the worst retention you can buy.
The month after, which is the part people skip
An app launch does not have a spike-and-plateau shape. It has a spike, a crash, and then whatever your real acquisition is. The month after is where you find out what that is.
- Watch day-1 and day-7 retention, and nothing else, until they are good. Every other number is downstream.
- Ship an update. Both stores treat an actively updated app better than an abandoned one, and a "what's new" note is a free reason to appear again.
- Answer every review, including the bad ones. It is visible to everybody else reading them.
- Get listed in directories, over the following weeks rather than in one afternoon. That is the part that keeps working after the launch traffic is gone — see where to submit your startup.
What actually moved the needle, honestly
For most independent apps, in order: the store listing, word of mouth from the first hundred users, being present in one community where the problem is discussed, and search — both the store's and Google's. Launch day is usually fourth or fifth on that list, and it is the one that gets all the attention because it is the only one that happens on a schedule.
Where this site fits
WhatAreYouBuilding.AI is a permanent listing rather than a launch. Your app gets a page, a do-follow link and a place in a catalogue organised by country and category. It is also queryable by agents via MCP, which matters more every month, because "what apps are there for X" is increasingly a question people ask a model rather than a search box.
Free, and a person reads every submission. Submit a product, or see what a listing gets you.