The Short Answer
What should you do after launching an MVP?
Compare the result with the success metric you set before launch, then measure product-market fit with active users: if at least 40% would be very disappointed to lose the product, build on it. If not, find what your most enthusiastic users value and change the product towards them, or stop. Only once the answer is yes should you invest in hardening the MVP for production and growth.
The common mistake is to treat launch as the finish line and start adding features straight away. Before building anything else, you need an honest read of what the MVP told you.
Read the Result You Got
If you set a success metric before launch, such as “10 paying gyms within 60 days”, the first read is simple. If you did not, set one now for the next 30 days and do not move it. Results usually fall into one of three groups:
| Result | What it looks like | Usual next step |
|---|---|---|
| Clear signal | Target met; users return without prompting; some pay or ask to | Measure fit, then harden and grow |
| Mixed signal | Some keen users, many who try once and leave | Find out what the keen users have in common and focus on them |
| No signal | Few sign-ups, little return use, no one asks for more | Talk to the people who left; pivot the problem or the customer, or stop |
A mixed signal is the most common and the hardest to read honestly. It is tempting to call it a slow start and keep building. The product-market fit survey below is the best tool for separating “some people love this” from “people are being polite”.
The 40% Product-Market Fit Test
How do you measure product-market fit after an MVP?
Ask active users how they would feel if they could no longer use the product: very disappointed, somewhat disappointed or not disappointed. Sean Ellis, who benchmarked nearly a hundred startups, found that companies with fewer than 40% very disappointed generally struggled to grow.
Marc Andreessen defined product-market fit in 2007 as being in a good market with a product that can satisfy that market. The definition is clear; measuring it is not. The most practical method is the survey question popularised by Sean Ellis and described in detail by Superhuman founder Rahul Vohra in First Round Review.
Superhuman surveyed users who had used the product at least twice in the past two weeks, and found results became directionally correct at around 40 respondents. It asked four questions:
- How would you feel if you could no longer use the product? (Very / somewhat / not disappointed)
- What type of people do you think would most benefit from the product?
- What is the main benefit you receive from the product?
- How can we improve the product for you?
Superhuman's first score was 22%, well below the benchmark. By focusing on the users who would be very disappointed, and on what held back the somewhat-disappointed users who shared their view of the main benefit, it reached 58% over the following three quarters.
Score Your Survey
Interactive calculator
Score your product-market fit survey
Enter how many people chose each answer to: “How would you feel if you could no longer use the product?”
0%40% benchmark100%
30% very disappointed
Below the 40% benchmark. Superhuman started at 22%: segment the very-disappointed group, ask what they value, and fix what holds back the somewhat-disappointed users who share that view.
Persevere, Pivot or Stop
- 1
Persevere
Score at or above 40%, and the success metric met. Protect what the very-disappointed group values, fix what blocks the somewhat-disappointed group, and start hardening the product.
- 2
Narrow
Score below 40% overall, but much higher within one type of customer. Rebuild your positioning and roadmap around that segment and resurvey.
- 3
Pivot
Low scores across every segment, but users describe a different problem they would pay to solve. Change the problem or the customer, and treat the next build as a new MVP.
- 4
Stop
Low scores, no strong segment and no better problem in the feedback. Stopping cheaply is the outcome an MVP exists to make possible.
Whatever you decide, decide it on a date. Running an unclear MVP for another six months spends runway without new information; CB Insights found 70% of shut-down venture-backed startups ran out of capital.
Taking an MVP to Production
Can you build on MVP code or should you rewrite it?
If the MVP was built as production software, with tests, a deploy pipeline and clean structure, build on it. If it was a prototype, a no-code build or rushed code with no tests, plan a rewrite of the parts that carry real customer data and money, ideally before growth makes it harder.
GOV.UK's Service Manual describes a similar transition: in beta, a team takes its best idea “and start[s] building it for real”, first with a limited group in private beta, then opening to everyone once it can run at scale. For a startup, the same move means these additions, usually in roughly this order:
Safety net
Automated tests on the core flow, error monitoring, uptime alerts and tested backups.
Security
Review access control (OWASP’s top risk), secrets, dependencies and personal data handling.
Operations
Staging environment, release process, on-call basics and a status page.
Scale
Performance work where real usage shows a bottleneck, not before.
Broken access control is ranked first in the OWASP Top 10:2025, so it is the first thing to review before you open the product to many more users. For the engineering practices behind each step, see production-grade software and incident response for a small team.
What to Build Next
After a positive result, the pull is to build everything users asked for. The Standish Group finding that half of software features are hardly ever used applies just as much to version two. Use the survey answers instead: build what makes the very-disappointed users' main benefit stronger, and what removes the obstacles for somewhat-disappointed users who value the same thing. Ignore requests from users who would not be disappointed to lose the product.
For turning that into a roadmap, see product strategy frameworks; for pricing once people are paying, pricing your SaaS product; and for opening to a wider group in stages, running a beta program.
Who Builds Version Two
The team that built the MVP knows the code best, which makes them the fastest option for the next few months. Make sure you own the repository and have documentation another team could pick up; see software ownership. Once the product has clear fit and a steady roadmap, hiring an in-house engineer usually starts to make sense: hiring your first engineer covers when and how.
If you need a team to harden an MVP or build version two on a fixed price, see Loomstrat's custom software development, or send a brief.
Frequently Asked Questions
What happens after an MVP?
You compare the results with the success metric set before launch, measure product-market fit with active users, and decide whether to persevere, narrow to a segment, pivot or stop. If you persevere, you harden the MVP for production and build version two from what your most engaged users value.
What is the 40% rule for product-market fit?
Sean Ellis’s benchmark: if at least 40% of active users would be very disappointed if they could no longer use the product, it has product-market fit. He found companies below 40% generally struggled to grow. Superhuman moved from 22% to 58% by acting on the survey.
How many users do you need for a product-market fit survey?
Superhuman found results became directionally correct at around 40 respondents. Survey active users only; Superhuman used people who had used the product at least twice in the past two weeks.
Should I rewrite my MVP?
Only if it was not built as production software. Code with tests, a deploy pipeline and clean structure can be built on. Prototype or no-code builds, and rushed code with no tests, usually need the parts handling customer data and payments rebuilt.
When should you pivot after an MVP?
When the fit score is low across every customer segment, but feedback points to a different problem users would pay to solve. If no segment scores well and no better problem appears, stopping is usually better than pivoting.
How long should you run an MVP before deciding?
Long enough to reach your success metric’s date and around 40 survey responses from active users. Set the decision date in advance so an unclear result does not run on indefinitely.
An MVP is only worth what you learn from it. Read the result honestly, decide on a date, and build version two for the people who would miss the product most.