The Ultimate Pre-Launch Checklist for Indie Apps
By Luis Krin, Founder, IndieAppCircle
Most indie launches do not fail on launch day. They fail two weeks earlier, when the developer skips the boring parts because the product is finished and the itch to announce it is strong. This checklist is ordered by when each item needs to be done, working back from launch, so you can see what is still open and what it costs to skip.
It assumes a solo developer or a very small team, no marketing budget, and an app that already works. If the app does not work yet, close this tab and go fix that first.
Four weeks out: positioning and plumbing
- One sentence that survives a stranger. Say what the app does and who it is for, out loud, to someone who has never seen it. If they ask “so what does it do?”, the sentence is not done. Everything downstream — the landing page, the store listing, the launch post — is a longer version of this sentence.
- A landing page that works on a phone. Most launch traffic arrives on mobile from a social feed. One headline, one screenshot of the real product, one call to action. If you are pre-launch, that action is an email field; if you are live, it is the signup.
- Analytics that answer three questions. Did they sign up, did they do the one thing the app is for, and did they come back. Plausible, PostHog or Simple Analytics all do this. Set up the three events now — retrofitting them after launch means losing the only week of data that matters.
- Error tracking. Sentry or equivalent, wired to something you will actually see. On launch day you will not be reading logs.
Three weeks out: real testers, not friends
This is the item most often skipped, and it is the one that decides whether the launch goes well. Friends and family will tell you it looks great. You need five to ten people who have never heard of the app, on their own devices, telling you where they got stuck.
- Recruit outside your circle. Other indie developers are the most reliable source: they understand rough builds, they write specific feedback, and many of them need testers too. The guide on how to get testers for an app covers every channel that works, and IndieAppCircle exists specifically to trade tests with other builders.
- Ask specific questions. “What do you think?” gets “nice.” “What did you expect to happen after you tapped that?” gets a bug report.
- Fix the first session. Empty states, the screen after signup, the moment where a new user does not know what to do next. Testers will find these; launch traffic will bounce on them.
- Watch someone use it without talking. One screen-share, ten minutes, you say nothing. It is uncomfortable and it is the single highest-yield hour before a launch.
Two weeks out: the gates you cannot rush
Several platforms have review steps with lead times that no amount of urgency shortens. Find out now which ones apply to you.
- Google Play, new personal account. You need 12 testers opted in to a closed test for 14 continuous days before you can even apply for production access, and the review after that takes up to a week. Budget three to four weeks total — see the guide to the 12 testers, 14 days rule. If you are two weeks out and have not started, your launch date is wrong.
- App Store. First submissions of a new app usually take one to three days in review and are rejected more often than updates are. Submit a build early enough that one rejection does not move the launch.
- Chrome Web Store, Shopify, Slack, and other marketplaces. All have a review queue. All reject first submissions for policy details — permissions justification, privacy policy URL, missing screenshots. Read the policy page once before you submit rather than after.
- Store listing assets. Screenshots at the required sizes, a short and a long description, a privacy policy URL (required almost everywhere now), and a support email that is not your personal inbox.
One week out: the launch itself
- Pricing decided and tested with a real card. If there is a paid tier, complete a purchase yourself on a real account, then cancel it, then check what happened to the account. Launch day is not when you discover the webhook never fired.
- Launch posts drafted, per platform. Product Hunt wants a maker comment that tells the story. Hacker News wants a plain “Show HN” with no marketing voice. Most subreddits ban self-promotion outright and the ones that allow it have rules — read them, because a removed post on launch day is worse than no post.
- A way to collect feedback inside the app. A button, a form, a mailto: link. Feedback that has to leave the app to be sent mostly does not get sent.
- What happens if it works. Rate limits, free-tier caps on your database and email provider, the API key with a monthly ceiling. A launch that goes well is the most common way to hit these.
- Email the list. If you collected addresses, warm them up now with a short “launching next week” note rather than a cold blast on the day.
Launch day
- Reply to every comment, everywhere, quickly. The replies are the marketing.
- Watch the three events from week one. If people sign up and never reach the core action, the problem is onboarding, and you can still fix copy today.
- Keep a hotfix build ready and ship nothing else. Launch day is for fixing, not for features.
- Write down what people ask. The questions you answer five times are the FAQ, the docs, and the next landing page.
The week after
The spike fades within 48 hours for almost everyone. What you do next matters more than the spike did.
- Talk to the people who came back. They are the template for who to find more of. Ask what they were doing right before they found you.
- Talk to the people who did not. One short email to signups who never returned: “what stopped you?” Reply rates are low; the replies are gold.
- Switch from spike to drip. Directories, communities, testing exchanges, and search all send a slow trickle that outlasts any launch. The guide to getting your first 100 users covers which channels are worth the time.
💡 Tip: Print this, or paste it into a note, and tick things off. Every item you cannot tick two weeks out is either something to do this week or a reason to move the date. Both are fine. Launching with it open is not.
Final thoughts
None of this is clever. It is the difference between a launch that produces a handful of confused signups and one that produces a handful of users who stay, and the whole list fits in a few evenings. The one item people cannot do alone is the testers — if you need people to use your app before strangers do, you can find app testers before launch on IndieAppCircle by testing a couple of other developers’ apps first.