Most apps fail after launch, not before. The common patterns are a launch with nobody to launch to, no budget left for the second release, feedback that is collected but not acted on, a team that disperses at launch, and success metrics that were never defined. The first ninety days should be planned before launch day: a quiet launch to a small group, daily attention to feedback in the first two weeks, one measured number, and a second release within six weeks.
Founders imagine failure as a launch that nobody notices. The more common failure is quieter: the app launches, some people use it, the founder does not know what to do next, and six months later the product is still version one with a dwindling user base. This post describes the patterns and gives you a plan for the ninety days that decide which way it goes.
The five post-launch failure patterns
1. Nobody to launch to
The product is ready and there is no list, no community, no partner, no audience. The founder starts marketing from zero on launch day. The first weeks, when the team is most available to fix and learn, pass with a handful of users. Prevention: build the waiting list and the first hundred users during the build, not after it. Our post on how long an MVP takes describes what to do while the product is being built.
2. Nothing left for version two
The budget was the build. Users arrive and ask for things, obvious things, things that would double retention, and there is no money and no team to do them. The product freezes at the moment it should be moving fastest. Prevention: reserve 20 to 30 percent of the total budget for the first improvements, and keep the development team available for six weeks after launch.
3. Feedback collected, not acted on
Support emails, app store reviews, analytics, all arriving, none of it turned into decisions. The founder reads everything and changes nothing, or changes everything and measures nothing. Prevention: one person owns the feedback, sorts it weekly into "fix now", "next release" and "later", and the team ships from the first list every week.
4. The team disperses at launch
The agency moves to the next project, the freelancer takes a new contract, and the first bug that blocks payments waits a week for someone to look at it. Real users find problems test users did not, and the first days after launch are when response time matters most. Prevention: a defined support period in the contract, with response times, starting on launch day.
5. No definition of success
Downloads are counted because they are easy to count. The number that matters, whether users come back and whether they pay, was never chosen, so nobody knows whether the launch worked or what to change. Prevention: pick one number before launch, instrument it, and look at it every day for the first month.
The ninety-day plan
| When | What happens | What you watch |
|---|---|---|
| Before launch | Waiting list ready, support inbox set up, analytics on the one number, launch checklist done, team on standby | That everything on the checklist is actually done |
| Week 1: quiet launch | Invite 20 to 50 people from the waiting list. Watch them use it. Fix what breaks daily. | Do they complete the core journey without help? |
| Week 2: wider launch | Open to the full list and public channels. Daily fixes continue. Personal replies to every piece of feedback. | The one number, daily. Crashes and payment failures, immediately. |
| Weeks 3 to 4: listen | Sort feedback weekly. Interview ten active users and ten who stopped. Decide the second release. | Where users drop off. What the returning users have in common. |
| Weeks 5 to 8: second release | Ship the highest-impact changes from what you learned. Usually two or three things, not twenty. | Whether the one number moves after the release. |
| Weeks 9 to 12: decide | Review the trend. Double down, adjust the target user, or change direction. Plan the next quarter and the funding it needs. | Retention over time. Cost to acquire versus value of a user. |
What to measure
One number that reflects real value. For a booking app, bookings completed per active user per month. For a marketplace, transactions. For a subscription product, users still active at day thirty. Downloads, sign-ups and page views are inputs. They tell you about marketing, not about the product. The retention number tells you whether you have something, and it is the number investors will ask for next.
What good looks like at day ninety
- A second release has shipped, based on evidence from real users.
- You can say what kind of user comes back and why.
- The one number has a trend, and you know what moved it.
- The team that built the product is still available, on a retainer or a scoped next phase.
- You have a plan and a budget for the next quarter.
None of that requires the launch to have been large. It requires the ninety days to have been planned.
How 7L handles the post-launch period
Every first release we deliver includes a support period from launch day, and we plan the second release with the founder before the first one ships, so that budget and team are ready for what users say. We help set the one number, instrument it, and read it with you at the weekly review. Launch is the start of the engagement's most useful phase, not its end. Ask us how we plan a launch.
Frequently asked questions
How big should a launch be?
Smaller than you think. A quiet launch to twenty to fifty people who wanted the product finds the serious problems while they are cheap to fix. A public launch a week or two later then lands on a product that works.
What if nobody comes back after the first use?
That is the most important thing you can learn and it is common. Interview the people who left. Usually the product did not deliver the value quickly enough, or it delivered value to a different user than you targeted. Adjust and release again.
How much should I keep in reserve for after launch?
Twenty to thirty percent of the total budget, plus the team's availability for at least six weeks. If that is not possible, launch narrower so that it is.
Should I respond to every app store review?
In the first months, yes. It is fast, it shows users someone is listening, and reviews are one of your few direct channels. Fix what the negative reviews describe and say so in the reply.
When should I start the second release?
Plan it before the first ships and start building around week four, once you have two or three weeks of real usage to learn from. Shipping it by week six to eight keeps momentum and shows early users the product is alive.