Getting an app into the stores is a solvable engineering problem with a known end point. Keeping it growing afterwards is neither, which is why so many competent teams ship something good and watch it flatten out within a quarter.
Post launch failure is rarely one dramatic event. It is a set of small unaddressed problems that compound while everyone is waiting for marketing to fix the numbers. These are the ones that come up most often, and what to do about each.
- Launch is the start of the learning phase, not the end of the project. Plan resource for the months after it.
- Read the retention curve, not the download count. Where it flattens tells you whether you have a product.
- Most churn happens in the first session. Fix activation before you spend anything on acquisition.
- Acquisition cannot outrun a retention problem. It only makes the leak more expensive.
- Talk to the users who left. They will tell you things your analytics cannot.
Section 01
The post launch cliff
The shape is familiar. Launch week brings a spike from friends, press and curiosity. Week two is quieter. By week six installs have settled into a trickle and daily active users are a fraction of total downloads.
This is normal and it is not, by itself, failure. What determines the outcome is what the team does next. The successful response is to treat the drop as data about activation and retention. The unsuccessful one is to treat it as a marketing shortfall and start buying installs into a product that is not holding them.
Acquisition spend on an app with a retention problem does not fix the problem. It just charges you more per user to observe it.
Section 02
Reading the retention curve properly
Retention by cohort is the single most informative chart you have after launch, and it answers a different question depending on where you look.
- Day one tells you about onboarding and first impression. A steep drop here means users did not understand or reach the value.
- Day seven tells you whether the value survived the novelty. This is where a curiosity separates from a habit.
- Day thirty tells you whether you have a product. If the curve flattens at a non trivial level, you have something worth investing behind.
- A curve that decays to near zero has no plateau, which means acquisition will never accumulate into a user base.
Compare cohorts over time as well. If each new week retains slightly better than the last, your changes are working, even when the absolute numbers are still small.
Section 03
Failure one: users never reach the value
The most common post launch problem is not that people dislike the product. It is that they never got far enough to form an opinion. They installed, hit a signup wall or an empty screen, and left inside ninety seconds.
- Measure time to first value and treat it as a primary metric, not a curiosity.
- Remove or defer anything between install and the core action, especially account creation.
- Design the empty state as a first run experience, because for every new user that is exactly what it is.
- Watch session recordings or run five sessions with real users. The blocking step is usually obvious within minutes.
Section 04
Failure two: nothing brings them back
Some products are used daily by nature. Most are not, and those need a deliberate reason to return rather than an assumption that users will remember.
- Identify the natural frequency of the problem you solve, and be honest if it is monthly rather than daily.
- Give returning users something that changed since last time, so opening the app is rewarded.
- Use notifications sparingly and specifically. Generic re engagement pushes buy one session and cost you the permission.
- Accumulated value helps: saved data, history and progress all raise the cost of leaving.
Section 05
Failure three: quality decays quietly
After launch the team moves to features and nobody owns the health of what already shipped. Crash rate creeps up, one screen gets slow, an OS update changes a permission, and each individually small issue removes a slice of users who never say why.
- Monitor crash free session rate as a standing metric with a threshold you act on.
- Track performance on real devices in the market you sell to, not on the team's phones.
- Test against OS betas before public release rather than after the reports arrive.
- Reserve capacity for maintenance every cycle so it never has to win an argument against a feature.
Section 06
Failure four: the feedback loop is never closed
Reviews get read and not acted on. Support answers questions without anyone aggregating them. Analytics are installed and never opened. The information needed to fix the product is arriving continuously and going nowhere.
- Read every review as a team, weekly. Categorise them so themes become visible.
- Reply to reviews, especially negative ones. Users frequently revise a rating when they see a response.
- Route support tickets into a tagged list so the top three issues are always known.
- Contact users who churned and ask one question about why. A handful of answers is enough to see the pattern.
- Close the loop publicly. When a release fixes something people complained about, say so by name.
Section 07
Failure five: scaling before the product is ready
This is the expensive one, because it looks like ambition. The team raises money or reallocates budget into acquisition while activation and retention are still weak, and burns the runway that would have paid for fixing them.
Section 08
What a working post launch model looks like
The teams that keep growing tend to run a similar rhythm, and it is not complicated. It is just maintained.
- A weekly review of retention, activation, crash rate and the top funnel drop off.
- A release every two to four weeks, held even when a feature slips.
- A standing split between new work and maintenance, agreed in advance rather than negotiated each cycle.
- Reviews and support themes read by the whole team, not just by whoever answers them.
- A single metric the team is currently trying to move, changed only when it has moved.
None of that requires a large team. It requires that someone owns the health of the product after launch as explicitly as someone owned shipping it.
Frequently asked questions
What retention rate should we be aiming for?
It varies widely by category, so the useful comparison is against your own earlier cohorts rather than against a published benchmark. What matters most is whether the curve flattens at all. A plateau, even a modest one, means you have a group of users who have found real value.
How long after launch should we wait before making changes?
Days, not months. Gather enough data to distinguish signal from launch week noise, usually one to two weeks, then start iterating. Waiting for a large sample before acting mostly means spending runway to be more confident about a problem you can already see.
Should we spend on marketing if retention is poor?
Only at a small scale deliberately intended to generate learning. Broad spend against a leaky funnel converts budget into churned users. Fix activation and early retention first, then acquisition compounds instead of evaporating.
Our app works well but usage is flat. What now?
Separate the two possible causes. If people install and do not activate, it is an onboarding or value clarity problem. If they activate and do not return, it is a frequency or habit problem. The fixes are entirely different, and the retention curve will tell you which one you have.
