In the 90 days after an MVP launches, your job is to learn, not to build. Weeks one to two: fix what is broken and watch every session. Weeks three to six: measure activation and retention, interview the users who stayed and the users who left. Weeks seven to twelve: decide between building on, pivoting and stopping, and ship a small version two aimed at the biggest drop-off. The founders who fail this stage are the ones who go straight back to the original feature list.
Launch day feels like a finish line and is actually the starting line. Everything before it was a guess about what users want. Everything after it is evidence. The 90 days that follow decide whether the MVP did its job, and most founders waste them by building the next thing on the list instead of watching what happened to the first thing. This is the plan we give founders at launch.
Weeks one to two: stabilise and watch
Real users do things no tester did. They enter names with apostrophes, upload 40 megabyte photos, lose connection halfway through checkout, and use the back button in ways that break state. The first two weeks are for catching that. Have the team on fast turnaround, fix what breaks the core journey the same day, and leave everything else on a list.
At the same time, watch. Session recordings, if your analytics support them, are worth more than any dashboard in week one. Watch twenty sessions and you will see where people hesitate, where they go back, and where they leave. Write it down. Do not fix it yet unless it is blocking the core journey.
Weeks three to six: measure and talk
By week three you have enough users for numbers to mean something. Five numbers matter, covered in detail in which metrics to track after launch:
- Activation. The share of sign-ups who complete the core journey once.
- Retention. The share who are back after a week, and after a month.
- Core action frequency. How often an active user does the thing the product is for.
- Acquisition cost against user value. Even rough.
- Source. Where the users who retain came from.
Then talk to people. Ten users who stayed, asked what they would miss if it disappeared. Ten who signed up and left, asked what they expected and what they found. The second group is harder to reach and more valuable. Offer a voucher. The patterns in those twenty conversations will explain the numbers, and the numbers will tell you which conversations to trust. How to test an MVP with real users covers how to run them.
What do the numbers point to?
| Pattern | What it means | What to do |
|---|---|---|
| Activation low, retention of activated users high | The product works. The path to it does not. | Fix onboarding and the first session. Do not add features. |
| Activation fine, retention low | People try it and do not need it again | Interview the leavers. The problem may be real but infrequent, or the product may be solving the wrong part of it. |
| Both fine, growth flat | The product works for the people who find it | Acquisition is the job now. Double down on the source that produced retained users. |
| Both low | The core assumption is wrong | Pivot or stop. Do not build version two of a product nobody wanted. |
| One segment retains, the rest do not | You found your user, and it is not who you planned for | Narrow to that segment. Rewrite the landing page for them. |
Weeks seven to twelve: decide and ship version two
By week seven you know which row of that table you are in. Version two follows from it, and it should be small: two or three changes aimed at the largest drop-off or the most repeated request, plus fixes from the list and a share of technical debt. When to build version two covers the sizing. What version two is not is the rest of the original feature list. That list was written before you had evidence. Some of it will survive contact with users. Most of it will not.
Ship version two by the end of the 90 days, measure the same five numbers again, and you have a loop. The loop is the product development process from now on.
What should you not do in the first 90 days?
- Build the second platform. If the web MVP has not retained users, the iOS version will not either.
- Rebuild. Three months of users is not enough to know what the architecture needs. See rebuild or keep building.
- Spend on acquisition before retention. Paying to fill a bucket with a hole in it.
- Raise on launch metrics. Downloads and sign-ups are not traction. Retention is. Wait for the week-four numbers.
- Go quiet. The early users are your best source of evidence and your first advocates. Reply to every message.
The 90-day checklist
- Analytics wired to the five numbers before launch day.
- Same-day fixes for anything blocking the core journey.
- Twenty session recordings watched and noted in week one.
- Ten retained and ten churned user interviews by week six.
- A one-page decision memo in week seven: build on, pivot, or stop.
- Version two shipped by week twelve, small and aimed.
How 7L runs the post-launch period
Launch is the start of the market entry phase of the Startupper Program, and the team that built the MVP stays on it through the first 90 days on a lighter cadence. We wire the analytics before launch, sit in on the user interviews, and write the week-seven memo with the founder. Most of our version twos are smaller than the founder expected and better aimed. If your MVP is live and the numbers are confusing, share them with us and we will help you read them.
Frequently asked questions
How many users do I need before the numbers mean anything?
A few hundred sign-ups gives usable activation and week-one retention figures for a consumer product. For B2B, five to ten active accounts with real usage tells you more than numbers will. Below those levels, rely on interviews and session recordings rather than percentages.
What retention rate is good for an MVP?
It depends on how often the problem occurs. A daily-use product should see 20 to 30 percent of activated users back in week four. A weekly-use product should see similar numbers over a month. A product used once a quarter cannot be judged on retention in 90 days, and you should measure whether users complete the job and recommend it instead.
Should I keep the development team after launch?
Yes, on a reduced cadence. The first two weeks need same-day fixes, and version two needs the people who know the code. A team that disappears at launch leaves you with a product that cannot change. Agree the post-launch arrangement before the build starts.
When should I start marketing an MVP?
Enough to get the first few hundred users, from the start. Paid acquisition at scale waits until week-four retention is healthy, because until then you are paying for users who leave. Our post on getting your first 100 users covers the channels that work at this stage.
What if the data says stop?
Then the MVP did its job, which was to find out cheaply. Stopping after an MVP costs a fraction of stopping after a full build. Most founders pivot rather than stop, keeping the segment or the insight that worked and reframing the product around it.