A practical launch checklist for your indie app

A launch is a set of connected user experiences: discovering the app, understanding it, obtaining it, using it and getting help. Treating those as separate checklists can hide the gaps between them. Start with the complete path a new customer will take.

Check the product's first useful session

Install the release build in an isolated environment and work through setup as a new user. Confirm that the supported operating-system requirements are accurate, permissions are explained and the first useful action is easy to find. Test the behavior when a model, network connection or optional provider is unavailable. A launch checklist should include recovery, not just the successful path.

Follow the purchase through to access

Make the price, currency, billing period and license entitlement explicit. Check that the checkout destination matches the offer on the marketing page. Using the provider's approved test workflow, verify receipt delivery, access to the correct files and the information required to activate a license. Do not assume that a successful payment automatically means delivery works.

A limited launch price needs a real limit in the sales process. Decide how the offer ends and what happens to refunded orders. If you cannot verify a remaining count, state the offer terms without displaying a live counter.

Make the website demonstrate the app

Use actual app views and short recordings of important tasks. The page should explain the product without requiring video playback. On a phone, check that headings, prices and controls remain readable, and that media does not delay the entire page. Verify navigation, external purchase links, support email and policy links.

Prepare support before announcing

Give customers one clear way to reach you and tell them which details help: operating system, app version, a description of the issue and an order reference when relevant. Explain where to find purchased files and how refunds are requested. Do not ask for passwords, provider credentials or an entire private workspace as an initial diagnostic step.

Give each remaining task an owner and a date

Separate release blockers from work that can follow the launch. Record a clear completion condition, any dependency and the date it is needed. In a solo project the owner may always be you, but naming the task still turns an intention into something you can review. A release date is useful only when it stays connected to the work required to meet it.

Product Vector keeps project work, launch planning, checklists and calendar dates in the same local workspace. Use those records to review readiness, record what actually happened and carry the lessons into the next version.