Reviewed examples, measurement limits and implementation advice; removed unsupported client-outcome claims.
- The store listing multiplies every other channel, and the first screenshot, title and subtitle do most of the work.
- The first 200 installs should come from people you can talk to, because they will tell you what the dashboard cannot.
- Review retention, crashes and useful in-app actions alongside acquisition cost before expanding paid campaigns.
- Measure cost per retained user, not cost per install, and expect attribution gaps you have to reconcile.
- Press releases, paid reviews and incentivised installs are the three launch line items we always cut.
Plan discovery and product use together. Buying installs before checking onboarding, crashes and retention can leave the team with an acquisition report and little understanding of whether people found the app useful. The sequence below is a planning approach, not a delivered-client result.
Fix the store listing before anything else
Every channel you use, organic search in the store, paid campaigns, a link from your website, passes through the store listing. Its conversion rate multiplies everything else you do.
Review the title, icon, description and screenshot sequence together. Show the task a user can complete and keep the promise consistent with the product. Test suitable listing changes where the store and available traffic allow it; there is no universal order of creative elements that wins for every app.
Write the subtitle for search terms someone would actually type, not for a slogan. Make the first two screenshots show the app doing the thing, with a caption explaining what is being looked at, rather than a phone floating on a gradient. Test the icon against competitors at real size on a real device, not at 512 pixels in a design tool.
Use the metadata fields each store currently supports. Research the language users use for the task and write an accurate listing, rather than assuming the Apple App Store and Google Play index identical fields in the same way.
Get the first 200 installs from humans
Before any paid acquisition, put the app in front of people you can have a conversation with: existing customers, an email list, a community you are genuinely part of, colleagues, a beta group.
Speak with people who tried the app and ask them to show where they got stuck. Combine those conversations with crash reports and usage data. Onboarding or device-specific fixes belong with the mobile development team, rather than being treated as a listing-copy problem. A small interview group can reveal problems, but it cannot guarantee that every serious issue has been found.
Use a staged rollout, watch the crash rate, and fix onboarding before you widen distribution.
Watch retention, not installs
The number that decides whether to spend money is day-7 retention: of the people who installed on a given day, how many opened the app a week later.
Benchmarks vary enormously by category, so compare against your own trend rather than an industry average. The logic is universal. If day-7 retention is very low, paid acquisition converts budget into uninstalls at a fixed exchange rate. Fixing retention first is not a delay, it is the thing that makes the spending rational.
The usual causes of poor early retention: onboarding that asks for permissions or an account before showing any value, a core action that takes too many steps, and a value proposition the store listing promised but the app does not deliver in the first session.
We do store listing work, creative testing and paid acquisition for apps, starting with the listing, because everything else multiplies through it.
Then, and only then, buy installs
When retention is acceptable, paid acquisition becomes worthwhile. Start narrow: one platform, one country, one audience, a small daily budget, creative that shows the app in use.
Compare acquisition cost with retained use and the action that matters to the business. As an illustrative example, an install costing USD 0.80 can be less useful than one costing USD 3 if only the latter becomes a retained customer. The conclusion depends on retention, conversion and margin, not install cost alone.
Track properly. Attribution on mobile has become considerably harder with platform privacy changes, so use an attribution provider, expect gaps, and reconcile against in-app events you control. Expect the numbers to disagree; decide in advance which source you will act on.
Build a review habit into the product
Ratings and reviews help people assess an app. Ask only after enough experience to give useful feedback, using the store’s review flow and a suitable point while using the app.
Use a neutral review prompt after enough experience with the app. Do not ask whether someone is happy, predict a rating or route only favourable responses to the store. Keep support available independently of the review flow. Google Play’s review guidance prohibits opinion questions before or during its rating prompt. Reply to public reviews, including critical ones, without using sentiment to restrict access to review.
Give the app a website
Give the app a useful website destination explaining its purpose, supported platforms, help and privacy information. Those pages can help customers and partners understand the product outside the store; publication alone does not establish organic search traffic.
It also gives you deep links, which improve the experience for anyone arriving from your own emails and campaigns. A page or two is enough; this is not a web development project unless you want it to be.
What we would not spend on at launch
Press releases, which nobody reads. Paid review services, which are against store rules and detectable. Incentivised installs, which destroy your retention data. Large-scale user acquisition before retention is proven. And a launch video costing more than the first quarter's ad spend.
A realistic ninety days
Agree a launch plan with listing review, measurement, crash reporting and product feedback first. Review onboarding and retention before expanding acquisition. The dates and number of early users depend on the product and audience; treat a timetable as a proposal to review, rather than a fixed result schedule.
Review the evidence from each stage before expanding the next one. Record what changed and what the available data can support.
When to get help
Listing work can benefit from an independent review of the copy, creative and measurement. Agree the work and its fee before commissioning it. Paid acquisition is worth handing over once the daily budget passes the point where a bad week matters. That split is how our app store optimisation and mobile advertising engagements usually start, and if the app itself is not built yet, the build decision comes first: Flutter, React Native or native.
Questions
How much should I budget for an app launch?
Separate product fixes, store listing work, measurement, management fees and media spend. Review onboarding, crashes and retention, then decide whether a limited acquisition test can answer a useful question. The budget depends on the product, audience and action you need to measure; it is not one fixed launch fee.
What is a good day-7 retention rate?
It varies too widely by category for a single number to be honest. Compare against your own trend: if retention improves as you change onboarding, you are on the right track. If it does not move, the problem is the product.
Does app store optimisation actually work?
An accurate listing and useful creative can help users assess the app. Results depend on demand, discovery, the product and the changes made. Review each store’s supported fields and testing options, and measure listing visits and installs separately from retained use.
Should I launch on both iOS and Android at once?
Only if you have the capacity to support both. Launching on one, learning, then porting is usually faster overall than splitting attention across two review processes and two sets of bugs.
How do I get reviews without breaking store rules?
Use the store’s official review flow after people have enough experience to give useful feedback. Do not offer incentives, ask them to predict a rating or filter who can review based on sentiment. Keep support available independently. Google Play’s guidance explains its prompt requirements.
Sam K (Santosh Kumar) founded Knit Infotech in 2013. Based in Noida, he works on web applications, ecommerce, CRM systems and workflow automation. He helps clients agree the scope and technical decisions behind a build.
