Why launching an app is not the final step

Launch day feels like an ending. Months of decisions, debates, and design reviews compress into a single moment: the app goes live, the team exhales, and there is a brief, genuine sense of completion. Then the downloads start coming in, and something quieter begins. Users arrive, look around, and leave. Most of them leave within days. A proportion of them leave within hours. And because they do so without filing a complaint or sending an email, the team often does not know it is happening.

Launching is the start of a different kind of work, and treating it as a destination is the most expensive mistake a team can make.

This is the part of mobile product development that does not get discussed at launch events. The live product is the start of a different kind of work, and the teams who treat launch as a destination tend to find out the hard way that their metrics were telling a different story from the one they believed.

What follows is what we have learned from working on products across that post-launch period, from an art-based auction game to a water tracking app, and from a grassroots football product to an anonymous messaging platform. The pattern across all of them is consistent: the launch is where the hard work becomes visible.

What 'launched' actually means for a mobile app

There is a version of 'launched' that means the app is live in the store, the build is stable, and the first users are arriving. That version is real and worth marking. There is also a version that teams sometimes carry into the weeks that follow, where 'launched' starts to mean 'finished', and that version is where problems compound quietly.

A live app is a product in its earliest, least-understood state. You have built something based on assumptions about how people will behave, what they will find useful, and which moments will feel rewarding. Some of those assumptions hold. Some do not. The only way to find out which is which is to observe real users moving through the product under their own motivation, without a researcher in the room and without the founder watching over their shoulder.

Simon's view, shaped by working across a range of mobile products, is that the teams who struggle most after launch are those who confused confidence in the idea with certainty about the execution. The idea can be sound and the execution can still miss. Launch is when the gap between those two things becomes measurable, and what you do with that measurement is what determines whether the product survives its first thirty days.

The retention cliff that catches product teams off guard

Download numbers are the easiest metric to watch, partly because they only move in one direction and partly because they arrive in real time. A team that has just launched an app will refresh the acquisition dashboard and see numbers climbing, and that climb feels like evidence that the product is working. The problem is that downloads measure interest, not value. They tell you how many people decided to try the thing, not how many found a reason to stay.

On average, 77% of apps lose their daily active users within the first three days of download, according to Business of Apps. Even well-built products typically see a 40 to 50 per cent drop in retention over the same window. The gap between those two figures, between 77 per cent and 40 to 50 per cent, is the space that strong onboarding and clear early value communication actually occupy.

We saw this directly on a water tracking app we developed. Download numbers were moving upward, which made the early period feel healthy. But the retention picture told a different story. Users were leaving in significant numbers at day three, day five, and day seven, and because they were leaving silently, the drop was not registering as a problem. We had been reading the acquisition data, and the retention data was running underneath it, largely unread.

Why silence from users is not the same as satisfaction

One of the more persistent assumptions in mobile product teams is that quiet users are happy users. The logic is intuitive: if someone had a bad experience, they would say something. They would leave a review, send a support request, or at least uninstall with a comment. The reality is that most of them do none of those things. They simply stop opening the app, and their silence gets filed away as approval.

Around 25% of apps are used only once after being downloaded, according to Statista. Those users did not write a review. They did not explain what went wrong. They made a decision without narrating it, which is exactly what most people do in most consumer contexts. Waiting for negative feedback to signal a retention problem is waiting for something that largely never comes.

Most users who leave do so without a word, which means their silence tells you nothing useful about why.

Between funding rounds on one project, we made the decision to implement much better tracking of user retention and to proactively ask users how things were going. That decision came from recognising that we had been using investor confidence as a proxy for product health, and that the two things were measuring different things entirely. Investor confidence reflects the vision. Retention data reflects the reality of daily use. We needed both, and for a period we only had one.

Set up retention tracking before launch, not after. Day 1, Day 3, and Day 7 retention rates should be visible from the first week. Waiting until a problem is felt rather than measured means losing weeks of recoverable ground.

What the first three days reveal about your product

The first three days of a user's experience are less about features and more about clarity. A user arriving at a new app is running a very fast, largely unconscious assessment: does this make sense, does it deliver something I wanted, and is it worth the friction of building a new habit around it? Most of that assessment happens before they have explored even half of what the app can do.

On one project, an art-based auction game, we had retention sitting in the mid-sixties to low seventies percentage range in its early period. Users were finding the core loop quickly, understanding what the game asked of them, and coming back because there was enough content to sustain the habit. Then the quantity of available games began to drop. Users who arrived and found limited options had no reason to return. Retention fell to around 30 to 35 per cent, and it fell because the first session stopped delivering on the promise the product had made.

The first three days do not reveal whether your feature set is complete. They reveal whether your core experience works well enough to earn a second visit, and then a third. That is a narrower question than it sounds, and it is the one worth answering first.

Map the critical path a new user takes in their first session and test it with people who have no prior knowledge of the product. If they cannot find the value within a few minutes without assistance, the onboarding is doing too little work.

Onboarding as the first test of trust

Onboarding is where most retention problems begin, and it is also the part of a product that teams are most likely to treat as a formality. The assumption is that a capable product sells itself once a user is inside it, and that onboarding is just the door. The data suggests otherwise. Research from AppsFlyer indicates that users who experience friction in their first session are 2.7 times less likely to return by Day 7.

We saw this play out directly on the anonymous messaging app we built, where upfront registration was required before a user could access any part of the product. Because we could not drip-feed value inside the app, all the context that would normally build through use had to be front-loaded outside it. We invested heavily in App Store listings, screenshots, and out-of-app content to communicate everything a user needed to understand before they even opened the product. The onboarding constraint became an acquisition problem, and solving it required working backwards from the moment a user encountered the app in the store.

Onboarding is also where trust is either established or forfeited. A prompt that asks for permissions or a rating before the user has had any meaningful experience inside the app is asking for something before delivering anything. The more measured approach is to wait until the user has had a genuinely positive moment, achieved something real within the product, and then ask. At that point the request feels earned rather than presumptuous.

When the real problem is the core experience, not missing features

When retention drops, the instinct on many product teams is to add something new. A new feature gives the team a sense of forward motion, signals activity to investors, and offers users something they did not have before. The difficulty is that a feature added on top of a broken core experience does not fix the core experience. It adds complexity to something that is already failing to hold people's attention.

The auction game problem

On the art auction game project, as retention fell from the mid-sixties to around 30 to 35 per cent, the client's response was to add new features to re-engage users. We raised the concern that the actual problem was the declining quantity of available games, which meant users arriving and finding nothing compelling to do. The feature additions proceeded regardless, and retention continued to fall. It was only when the numbers reached that low point that the focus shifted back to the core content supply problem. When enough games were available again, retention returned to the mid-sixties to low seventies, though rebuilding the trust that had eroded in the intervening period took considerably longer than fixing the supply issue itself.

What to address first

The sequence matters. Before adding features, the question worth asking is whether the fundamental user journey, the core reason someone opens the app and keeps opening it, is working as well as it should. If the answer is no, additional features are unlikely to compensate. They are more likely to obscure the problem until it becomes harder to diagnose.

When retention drops, audit the core user journey before scoping new features. Walk through the primary loop as a new user would and ask whether it delivers something worth returning for. Often the answer is in the basics, not in what is missing.

How investor confidence became a proxy for product health

Raising investment is a genuine signal of something. It means people who have seen a great many ideas have looked at this one and decided it merits a bet. That signal is meaningful in the right context. The problem is when it gets used to answer questions it was never designed to answer, specifically questions about whether real users are finding the product useful and coming back to it.

We worked through this directly between funding rounds on one project. Investor confidence had been functioning as a kind of health indicator for the product: if sophisticated people with pattern recognition for these things believed in it, the product must be in a good place. What that logic did not account for was that investors were betting on the vision, the market, and the team. Users were doing something far simpler: deciding, in the moment, whether the app was worth opening again.

The decision we made was to put in much better tracking of user retention and to proactively solicit feedback from users about how things were going. Those two things, one quantitative and one qualitative, gave us a picture of product health that investor confidence had never been able to provide. They are measuring different things, and treating one as a substitute for the other is a clean way to stay comfortable while a real problem goes unaddressed.

Iterating after launch without losing direction

The case for launching earlier rather than later is about recognising that the feedback a live product generates is worth more than the additional polish a longer pre-launch period produces. No amount of internal review replicates what happens when real people, with their own contexts and expectations, interact with something under their own steam.

We have seen both failure modes. The fitness and wellness app and the grassroots football product both involved founders with strong conviction in their vision who found it difficult to act on the data coming back from research, focus groups, and surveys. The signs were consistent: a drive to perfect the product before launch, rolling back sign-offs to request further changes, and decisions that took far longer than the budget could sustain. Both projects used their budgets in design and build without ever reaching a fully live version of the product. The conviction was real; the willingness to iterate on evidence was not there.

Iterating after launch means deciding what the data is telling you and making a call on it. That requires a clear sense of what the product is for, because without that, every piece of feedback becomes equally plausible and nothing gets prioritised. The product vision holds the iteration process together. Without it, each cycle risks pulling the product in a different direction from the last one.

1. Define what success looks like in the first 30 days before launch, not after.
2. Identify the two or three retention metrics that will tell you whether the core experience is working.
3. Set a review point at day seven and day thirty, with a decision framework already in place for what each scenario requires.
4. Separate feedback on the core experience from feedback on features, and address the core first.

Building trust with users over time

Trust in a product is not established at the moment of download. It builds through repeated positive experiences, and it erodes through friction, confusion, or the feeling that the product is not quite delivering what it suggested it would. A user who returns on day three and finds the same value they found on day one is on their way to becoming a retained user. A user who returns and finds something unclear, broken, or less compelling than they remembered is probably not coming back on day seven.

This is why the period after launch matters more than the period before it. Pre-launch, you are making promises through marketing, store listings, and word of mouth. Post-launch, every session is either keeping or breaking those promises. The gap between the promise and the experience is where churn lives.

One practical dimension of this is knowing when to ask for something from a user. Asking for a rating before they have experienced value costs you the trust you have not yet built. Asking after a genuinely positive moment, after they have completed something meaningful inside the product, frames the request differently. It feels like an invitation rather than an obligation, and users who are in a positive emotional state at that moment are far more likely to respond in a way that reflects the actual quality of the product.

• Delay permission requests until the user understands what they unlock.
• Place rating prompts after a completed action, not on app open.
• Make the path back to value as short as possible for returning users.
• Treat app updates as trust signals, and communicate what changed and why.

Conclusion

The moment a product goes live is genuinely worth celebrating. It represents a real commitment of time, money, and decision-making under uncertainty, and not every product makes it that far. But the work that comes after launch is where the actual relationship with users is formed, and that relationship is built or lost in the first few days, before the team has even processed that the launch is over.

Retention is the measure that matters. Downloads tell you about interest. Retention tells you about value. The two move independently of each other, and a product that reads its download numbers as a proxy for its retention health is going to miss the actual story until the gap is too wide to close quietly.

What we have found, across the auction game, the water tracker, the anonymous messaging app, and the funding round work on retention tracking, is that the post-launch period rewards honesty about what the data is showing. Not the data that confirms the original vision, but the data that shows where real users are leaving, what they are not coming back for, and which parts of the core experience are not yet earning the habit that the product needs to survive.

If you are approaching launch or working through what comes after it, let's talk about your retention strategy.

Frequently Asked Questions