After the MVP: What to Build Next, and What to Leave Alone

Launch day feels like the finish line. It is really the start of the part where you learn the most. An MVP (minimum viable product, the smallest real version of your product) exists to answer one question: will people use this, and will they pay? The weeks after launch are when you get that answer. They are also when it is easiest to lose focus, because every user, investor and friend has an idea for what you should add. This article gives you a simple order of work for the first months after launch.

The first weeks: what to measure

You do not need a large dashboard. You need a few numbers that tell you if the product does its job. Before launch, decide which ones you will look at, and write them down.

• Sign-ups. How many people create an account. This tells you if your message reaches the right people.
• Activation. How many of them finish the main path at least once, for example book a first class or send a first invoice. This is often the most useful number of all.
• Return. How many come back a week or a month later and use it again. A product people use once and forget has not solved their problem yet.
• Payment. How many pay, if you charge. And how many stop paying.
• Where people stop. The screen or step where most users leave the main path.

Numbers tell you what happens. They do not tell you why. So talk to users too. A short call or a few written questions with five or ten of them will explain most of what the numbers show. Also keep an eye on error monitoring, the tool that warns you when something breaks, so you hear about problems before users write in.

Be patient with small numbers. With a few dozen users, one person can change a percentage a lot. Look for patterns over several weeks, not for one good or bad day.

Fix what slows users down first

Before you build anything new, look at the places where people get stuck. This work is less exciting than a new feature, but it often moves your numbers more.

• Steps where people leave. If many users stop at the same screen, something there is unclear, too long or broken.
• Questions you answer again and again. If three users ask how to do the same thing, the product should explain it, not you.
• Slow screens. Check the main path on a normal phone with a normal connection, not only on your own laptop.
• Small bugs. One small bug is easy to forgive. Several of them make people doubt the whole product.

A good rule is to make the main path smooth before you make the product bigger. A new feature on top of a path that people abandon will not help much.

How to choose the next features

When you built the MVP, you probably wrote a list of ideas for later, as we suggest in what to put in an MVP. That list is a good start, but it was written before you had users. Now you have better information. Use it.

• Collect every request in one place. A simple list or table is enough. Note who asked, and what they were trying to do.
• Look for repeats. One loud request is a story. The same request from many users is a signal.
• Ask what they were trying to do. Users often ask for a solution, for example a new button. The problem behind it may have a simpler answer.
• Prefer what helps the main path. A feature that makes more people finish the main path, come back or pay comes before a feature that serves a new kind of user.
• Do it by hand first. If you can do something by hand for your first users, such as a reminder email, do that until you know it matters.
• Change one thing at a time. If you ship five changes together and the numbers move, you do not know which change did it.

Be careful with your own wishes, and with requests from people who do not use the product. They can be good ideas. But the people who use it every week are the ones whose problems you are paid to solve.

Users tell you what they need through what they do, more than through what they ask for.

When to invest in stability and scale

A well-built MVP can carry a lot more users than it has on day one. So you do not need to prepare for a million users now. But some signs tell you that it is time to invest in the base of the product, not only in new features:

• Errors are rising. Error monitoring shows more problems each week, or the same problem keeps coming back.
• Screens get slower as data grows. A page that was fast with fifty users is slow with five thousand records.
• You do too much by hand. Tasks that took ten minutes a week now take hours.
• More is at stake. More money passes through the product, or you sign larger customers who ask how you protect their data.

Investing in stability means things like tested backups, faster pages, clearer error alerts, and a security review of who can see which data. None of it is visible to users. All of it is what lets them trust the product as it grows.

When a version 2 or a rebuild makes sense

A version 2 is not the same as a rebuild. A version 2 is a larger step on the same base: a new type of user, a new paid plan, or iOS and Android apps once the web version has proven the idea. It makes sense when the numbers show that the first version works and users clearly ask for the next step.

A rebuild means replacing the base itself. It is rarely the right first move after an MVP. It makes sense only when the base blocks growth: every fix breaks something else, the way data is stored no longer fits the product, or security problems are built into the foundation. We explain how to decide in rebuild or fix a half-built app. Even then, what you learned from real users is not lost. It becomes the brief for the new base.

Keep a small budget for upkeep

Software does not stay healthy by itself. The libraries it is built with get updates, often for security. Outside services change how they work. Phones and browsers change. Small bugs appear as users do things nobody planned for.

So when you plan your budget after launch, do not spend all of it on new features. Keep a fixed part each month for upkeep: updates, small fixes and checks. It costs far less than an emergency, and it keeps the product ready for the next step. Many studios, us included, offer this as a care plan after launch. Whoever does it, make sure someone is clearly in charge.

The bottom line

After the MVP, the order of work is simple. Measure a few numbers and talk to users. Fix what slows them down. Add the next features from what many users do, one change at a time. Invest in stability when real use asks for it, and keep a small budget for upkeep. If you want to see how launch and the steps after it fit into a project, read an MVP in six weeks, week by week, or see how we build and improve MVPs.