MVP Iteration: How to Improve Your App in the 6 Months After Launch

What MVP iteration actually is

A minimum viable product is built to answer one question: will people use this for its core job? Once it is live, the answer starts arriving, and it is rarely a clean yes or no. Some users love one part of it, most drop off at a certain step, and a few use it in a way nobody planned. MVP iteration is the work of reading those signals and changing the product, release by release, until the core action happens reliably.

That is different from simply continuing the original roadmap. The roadmap was written before anyone used the app. Iteration replaces guesses with evidence, which is why the list of what to build next after launch rarely matches the list from before it. Our guide to the MVP launch covers the first 30 days; this one picks up from there.

The MVP iteration loop

Every useful iteration follows the same four steps. The faster you can go round this loop, the faster the product improves.

The loop works only if the people who built the product stay close to it. When the team moves on after launch, every small change becomes a new project with a new quote, and the loop slows to a crawl. That is why we plan the months after release as part of every MVP app development engagement, not as an afterthought.

How to decide what to build next

After launch, the list of ideas grows faster than any team can build. Sort every request on two questions: how much will it move the core number, and how much work is it? That gives four groups.

The most common mistake at this stage is the same one we see before the build: features modelled on the biggest apps in the category instead of the main value for the user. The quadrant keeps that impulse in check, because a feature has to earn its place with evidence. How we decided what belonged in the first version is in MVP app features.

A release rhythm for MVP iteration

Small, frequent releases are the engine of MVP iteration. In the first one to two months, aim for a release every one to two weeks. Each one is small: a fix, a clearer step, one improvement to the core flow. Users notice that the product listens, and you see the effect of each change on its own instead of guessing which of ten changes made the difference.

After the first months, most products settle into a monthly rhythm with one meaningful improvement per release and fixes in between. Every store submission is reviewed again, so a steady rhythm of small releases is easier to manage than one large update that waits on review at the worst moment.

Write a short note with each release for your first users: what changed and which of their messages it answers. It costs five minutes and it is the clearest signal that their feedback matters, which is also what keeps them giving it.

Plan the capacity for this in advance. A small team that can release in days is worth more in the first months than a larger team that needs a new estimate for every change. Agree on a monthly budget of hours or a fixed set of releases with whoever builds the product, so MVP iteration never waits on a contract.

What to measure during MVP iteration

Good MVP iteration needs very few numbers, but they have to be the right ones. Start with the core action: the one thing that proves the product does its job. For a booking app it is a completed booking, for a field tool a job recorded in the app instead of on paper, for a community app a member who comes back in the second week, for a subscription product a renewal.

Next, measure the path to that action. Where do people stop between opening the app and completing it? A funnel of five to eight steps is enough. The step with the biggest drop is almost always the best candidate for the next release, and fixing it usually moves the core number more than any new feature.

Then watch return. How many people who completed the core action once do it again a week or a month later? Return is the closest early signal of whether people will pay or recommend the product, and it is the number investors ask about first.

Finally, keep a qualitative channel open. A group chat with early users, a weekly call with one customer, support messages read by the founder rather than filtered. Numbers tell you where the problem is; conversations tell you why. MVP iteration that relies only on dashboards tends to optimise the wrong step, and iteration that relies only on conversations tends to build for the loudest user.

Write the four numbers on one page and look at them every week with the team. When the page stops changing, the product has settled, and it is time to plan the next larger milestone rather than the next small release.

The first six months of MVP iteration, month by month

Every product is different, but the order of work after launch is remarkably consistent across the projects we have been part of.

If the core number does not improve after the first two months, do not move on to month three. Go back to the problem, because adding features to a product whose core job does not work only makes it more expensive to change later.

MVP iteration in real projects

• Workarounds showed the next release. On TimeFix, before the app covered one case, technicians started writing things down in their phone's notepad. Within days the system and reality no longer matched, and the next release covered that case. Real use also showed that the work timer had to keep running with the screen locked or during a call made from the app.
• Real users before the wider audience. On EveSport, trainers ran real sessions with their own clients before the public launch, and fixes from that group shipped first. Bookings grew 18% in the first 60 days.
• The field changed the plan. On Liniowiec, the first trips on the water showed lost connections and wrong map positions that no simulator had revealed. Those fixes went in before the wider rollout, and the client came back to build the next stage on the same foundation.
• Pricing that can change without a release. On Body Vibes, the paywall reads its values from the backend, so the owners can change offers without a developer. Deciding that before the build saved a release every time the pricing changed.

Iterate or rebuild?

Sooner or later every founder asks whether to keep improving the first version or start again. Most of the time the answer is iterate. Rebuilding makes sense in a few specific situations.

A rebuild is rarely all or nothing. Often the backend or one module is replaced while the rest keeps running. If you are inheriting code from another team, read taking over an existing mobile app first, and for Flutter products adding features to an existing Flutter app.

MVP iteration mistakes that cost the most

• Building the loudest request. One persistent user is not a market. Weigh requests by how many people they affect and how close they are to the core action.
• Changing five things at once. When the number moves, you will not know why. Change one thing per release in the early months.
• Measuring downloads. Downloads measure the store listing. Repeated use of the core action measures the product.
• Letting the team go after launch. Iteration needs the people who know the code. If they are gone, even small changes start from zero.
• Iterating on a broken core. If the core number does not move, adding features hides the problem instead of fixing it.

Over time, iteration blends into ongoing upkeep. What that involves is covered in mobile app maintenance services. The idea of short build, measure and learn loops comes from the lean startup approach.

FAQ

Related guides