App launch checklist for indie developers

Treat launch as a set of verified gates. Before you announce the app, use one copyable control sheet with an owner, status, evidence, and follow-up for every gate.

01 Use a proof-based launch gate

Every item needs an owner, a status, retained evidence, and a follow-up. “Done” without evidence is not a launch gate.

Keep the sheet small by including only conditions that can change the launch decision or require a named check afterward. Keep audience and channel choices in the app marketing plan, and keep the detailed device matrix in the routing QA document. This checklist coordinates whether the release is ready to proceed.

Write one verifiable result per row. If iOS and Android have different owners or evidence, split them into separate rows. Leave the status open or blocked until a teammate can inspect the retained evidence, then use the follow-up field to record the next action instead of expanding the checklist with loose ideas.

02 Clear the store and release gates

Select the exact release build, finish the live listing and required declarations, clear current console errors, choose release control, and retain the approved or release-ready status. Automated checks reduce risk, but they aren’t exhaustive.

Store requirements vary with the account, app category, monetization, content, and target regions, so clear every task displayed in the current console instead of treating this table as a complete field list. Review timing also varies: use the status shown by Apple or Google, keep the gate open or blocked until the named evidence exists, and choose your own review point and contingency for anything still pending.

03 Prove the release build and support path

Test the release candidate’s core action, account or payment path when applicable, failure and recovery behavior, support and privacy destinations, and the supported devices your listing promises. Record the build and version you tested, along with evidence for each result.

1. Install the exact release candidate. Use the build selected for submission or production release, then record its build number, version, test date, device and operating-system version. If you replace that build, reopen the gate and repeat the affected checks. A passing result from an older build isn’t evidence for the release candidate.
2. Complete the app’s core action on real supported devices. Start from a fresh install and follow the main path a new user needs to complete. For a camera app, that might mean granting permission, capturing an image and saving or exporting it. For an account-based app, include account creation or sign-in only if the app requires it. Test across the device and operating-system range you claim to support, giving priority to the combinations your listing and support policy promise.
3. Check optional account and payment paths. If the app supports sign-in, test valid credentials, invalid credentials, sign-out and the recovery method you provide. If it sells subscriptions or other purchases, use the platform’s appropriate test environment to verify the purchase screen, successful access, cancellation or dismissal, and restoration when your product supports it. Skip these checks when the app has no account or paid path; don’t add a generic payment task just to make the checklist look complete.
4. Force likely failures and prove recovery. Deny a permission, interrupt the network, submit invalid input and retry an interrupted action where those conditions apply. Confirm that the app explains what happened, preserves data when it should and gives the user a workable next step. Save a screenshot, screen recording or issue record for the result. A crash-free happy path doesn’t prove that a user can recover when a dependency fails.
5. Open every support and privacy destination from the shipped app and listing. Check the support link, contact method, privacy policy and any account-deletion or help path your app actually presents. Confirm that each destination loads, matches the current product and can be used without access that a stranded user may not have. Treat broken, placeholder or outdated destinations as launch blockers when the app or store listing promises them.
6. Review automated findings, then make a manual go or no-go decision. Google Play pre-launch reports can surface stability, Android compatibility, performance and accessibility issues, but automated tests can’t guarantee that they will find every problem. Triage each relevant finding and retain the report or resolution note, while keeping manual QA as the evidence for your release gate.

Attach each result to the exact release candidate and promised device coverage. If a feature, device class or payment path doesn’t apply, record that condition instead of an unqualified pass.

04 Freeze and record the final campaign route

Freeze one canonical campaign URL after the App Store and Google Play URLs are final. Add a useful website fallback and record any custom rule that intentionally changes the route.

Use the same base smart link across launch placements, then add consistent campaign tags for each profile, post, ad, email or partner placement. This keeps the destination configuration stable while the placement labels remain explicit. With AppRoute smart routing, one public URL can send iPhone visitors to the App Store, Android visitors to Google Play and other visitors to the website fallback. Active custom rules can change that result, so include their conditions and order in the launch record.

Copy this compact destination record into your launch-control sheet:

Treat a rule as part of the release configuration. An active custom rule may intentionally override the basic store routing; an old rule may do so accidentally. Have the link owner compare the saved record with the current configuration before marking this gate ready, then retain a screenshot or saved configuration record that identifies the exact canonical URL and destinations.

05 Test the link and QR from real placements

Test the final URL from the placement people will actually use. Record the expected destination beside the observed result, and label each test request so you can separate it from launch traffic later.

1. Give the final URL a consistent campaign label. Start with one canonical smart link, then add a small, readable UTM convention: utm_source for the platform or publisher, utm_medium for the placement type, and utm_campaign for the launch campaign. Add a clearly marked test value, such as utm_content=prelaunch-test, while you run checks. The UTM cheat sheet has the naming pattern and examples; the important part here is that everyone testing the placement uses the same approved URL and that test requests remain easy to recognize.
2. Open the link from the placement people will use. Put the final URL into the actual profile field, scheduled post, ad preview, email button, or other approved placement. Tap that rendered link instead of pasting it into a browser. This catches placement-specific problems such as a truncated URL, an outdated draft, or a social app opening its own in-app browser. Record the placement name and the exact URL you tested.
3. Check each relevant destination and browser context. At minimum, test from an iPhone, an Android device, and a desktop browser, plus the social or in-app browser used by the campaign. Before each test, write down the expected result: App Store, Google Play, or the website fallback. Then record the destination that actually opened, the device and browser context, the time, and a screenshot or other evidence. If you use custom routing rules, include the contexts those rules are meant to handle. The routing recipes contain the fuller expected-versus-observed matrix; keep this launch gate focused on the routes that the approved campaign will exercise.
4. Scan the QR in its finished form. An AppRoute QR code encodes the smart link, so it should enter the same routing flow as a tap. Test the QR at its final printed or displayed size, with the intended contrast and viewing distance, on the devices your placement needs to support. Confirm both scan reliability and the resulting destination. If you later edit the smart link's destination, the short URL in the QR stays the same while the link and domain remain active, but you still need to scan it again. See AppRoute QR codes for how the QR and smart link work together.
5. Compare the record and resolve every mismatch. Put the expected destination beside the observed destination and assign any correction. After a change to the URL, routing rule, destination, placement, or QR presentation, repeat the affected check and retain the new evidence.

06 Record the baseline before traffic arrives

Capture the comparison window and baseline in the system that owns each signal. Link requests, installs or opens, support issues, and revenue are different evidence layers. Write down the starting value, where you found it, and who will check it after launch.

Use the same window definition when you return to the table, and note any filter or tracking change that breaks the comparison. If a number has no named source or owner, it isn't ready to serve as a launch baseline.

07 Run the launch-day control sheet

Reconfirm live availability and the complete route, start distribution only after critical gates pass, assign one observer, and log issues and decisions in the same sheet. An approved build, a working redirect, and a quiet dashboard cover different parts of the launch path.

Copy this table into the document your team will keep open during launch. Its blank fields are a reusable procedure, not a customer result.

Use go only when the intended live releases are available, the core path passes, every active campaign placement reaches its expected destination, the baseline is recorded, and an observer plus escalation contact are present. Use no-go when a critical check fails or lacks an owner and evidence. Pause distribution, record the failure and decision, assign the follow-up, and rerun the affected check before changing the status.

08 Make the first review a correction pass

At a preselected review point, compare current evidence with the baseline, separate routing failures from listing, product, and support issues, fix the highest-impact confirmed problem, and schedule the next check. There is no universal review interval or success threshold; choose a point that fits your launch and use the current evidence in your control sheet.

Use four questions to keep the review bounded:

1. What changed from the baseline? Compare the same measures and note the window you used. In AppRoute click analytics, inspect available campaign, device, and source context while accounting for missing context, preview bots, and repeat requests.
2. Where does the evidence break? If requests never reach the intended destination, inspect the link and routing setup. If routing works but later outcomes or support signals are weak, inspect the store listing, app, checkout, and support systems that measure those stages.
3. What is the highest-impact confirmed problem? Pick one issue supported by evidence, assign an owner, and record the correction. Don't turn an unexplained difference between systems into a diagnosis.
4. What happens next? Add the follow-up evidence you expect, set the next review point, and keep unresolved discrepancies in the control sheet.