What Should Your MVP Prove? Pay, Come Back, Fund or Sign: Pick One Test Before You Build

Why an MVP can only prove one thing

An MVP is an experiment. An experiment with four goals has no clear result. Say you launch with payments, push reminders, an investor demo flow and a team account. Three weeks later, few people have paid. Why? The price may be wrong, the reminders may be annoying, or the core feature may not be useful enough. You can't tell, because you changed everything at once. With one test, the answer is readable. If the goal was "people come back" and they don't, you know where to look: the core loop. One test also keeps the scope small. Every feature is judged by one question: does this test need it? If not, it waits for v2.

The four tests, side by side

A founder raising money and a founder testing willingness to pay should not build the same v1. For each test, here is what the MVP must include and what you can skip. Pick one row.

• People will pay. What the MVP must include: real checkout (Stripe or in app purchase). What you can skip: free tier, referral system.
• People will come back. What the MVP must include: the core loop, plus reminders or push notifications. What you can skip: payments, if you can delay them.
• Investors will fund you. What the MVP must include: a polished core flow, live in the stores or on the web. What you can skip: edge cases, admin tools.
• A business customer will sign. What the MVP must include: the workflow their team uses daily. What you can skip: self serve onboarding, pricing page.

Test 1: People will pay

Pick this test if your biggest doubt is the price, or whether the problem hurts enough for people to spend money on it. If this is your test, check what payments add to your build first. Our feature cost guides break down checkout, subscriptions and in app purchases. What goes in and what stays out:

• Build. The core feature and a real way to pay. A "notify me" button or a survey answer is not payment. People say yes to surveys far more easily than they enter a card.
• Skip. Free plans, referral codes, discount logic, multiple pricing tiers. One price, one checkout.
• Example. A small landlord app that tests whether landlords will pay a monthly fee to collect rent and log repairs in one place. The rent flow and the subscription are in. Tenant chat, reports and accounting exports are out.

Test 2: People will come back

Pick this test if people clearly want the idea, but you don't know if it becomes a habit. What goes in and what stays out:

• Build. The core loop, the few screens the user goes through again and again, and a reason to return: a reminder, a push notification, new content.
• Skip. Payments, if you can delay them. Charging too early can hide the answer: people may leave because of the price, not the product.
• Example. A workout app where a personal trainer sends a weekly plan and the client ticks off each session. The plan builder, the client view and a reminder are in. Payments, nutrition tracking and chat are out.

Test 3: Investors will fund you

Pick this test if your next step is a round, and the app's job is to make the pitch real. The app is only part of the pitch. Our guide on what to put in an MVP demo video and data room covers the rest, and our investor and fundraising guides go further. Want to know which flow to polish for your round? Book a call. On the call, we tell you what fits in a fixed-price build. What goes in and what stays out:

• Build. One core flow, polished, live on the web or in the App Store and Google Play. An investor should be able to open it on their own phone, not watch a mockup.
• Skip. Edge cases, admin tools, settings pages. Investors judge the main flow, not what happens when a user changes their email twice.
• Example. A booking app for clinics with the patient flow working end to end, from picking a slot to getting a confirmation. The clinic's back office runs by hand for now.

Test 4: A business customer will sign

Pick this test if you sell to companies, and one interested team is waiting to try something real. What goes in and what stays out:

• Build. The exact workflow their team uses every day, done well. Their staff will use it on real work, so the one flow must not break.
• Skip. Self serve onboarding and a pricing page. You will set up the first customer yourself, and the price is agreed in a conversation, not on a web page.
• Example. A reception tool that lets a clinic confirm tomorrow's appointments without calling each patient. The confirmation flow is in. A sign up page for other clinics is out until the first one signs.

Write your pass or fail line

Once you've picked a test, write how you'll know it worked. Keep it to something you can count once the app is live. You set the number yourself, from your own goals. The point is to decide before launch, so you don't reread the results to fit your hopes. For example:

• Come back. "Clients open the weekly plan their trainer sends them."
• Pay. "Landlords who try it pay rent through it the next month."
• Sign. "The clinic keeps using it after the trial week."
• Fund. "Investors who see the live app ask for a second meeting."

Three rules for a good line

Want to sanity check the idea before picking a test? Our free app idea validator asks the right questions in a few minutes. A good pass or fail line follows three rules:

• 1. It counts actions, not opinions. "Users say they like it" is not a result. "Users open it again" is.
• 2. It has a time limit. "In the first month" or "after the trial week". Without a date, you wait forever.
• 3. It says what happens next. Pass means you build v2 around the test. Fail means you change one thing and run it again.

Signs you haven't picked yet

Your test is still unclear if:

• Your feature list has both checkout and a free tier.
• You want an investor demo and a team admin panel in the same v1.
• You can't say which feature you'd cut first.
• Your success line uses "engagement" or "traction" with nothing to count.

How to find your test

Ask yourself: what's the one doubt that would stop me if the answer were no? That doubt is your test. Once the test is clear, the next step is writing down the scope for a builder. Our guide on how to write a PRD as a non-technical founder takes you through it.

How the test shapes our build

At BuildMVPFast, the test you pick decides what goes into your first version. See the full scope on our MVP development page. Once the test is clear, the scope is simple:

• Fixed at $3,460, with a fixed quote given before we start.
• Your app on web, iOS and Android.
• Delivered in about 20 days, with progress shown every week.
• Design included.
• The code is 100% yours, on your GitHub.
• 2 weeks of fixes after launch.

What is an MVP supposed to prove?

One assumption about your business: that people will pay, come back, fund you or sign. It is not meant to prove the full product works. That comes later, once the first test passes.

Can an MVP test two things at once?

It can, but the results get hard to read. If two things change and the numbers are weak, you won't know which one failed. Run one test, then the next.

Should my MVP include payments?

Only if your test is "people will pay". For a test on coming back, a business pilot or an investor demo, payments can usually wait for v2.

What if my MVP fails its test?

That's a result, not a loss. Change one thing, such as the price, the user or the core loop, and run the test again. This is why a small, fast first version matters.

How long does it take to build an MVP for one test?

It depends on the scope the test needs. A narrow test keeps the build short. Ours are delivered in about 20 days. Know your test, or want help picking it? Book a call. Your app on the web, iOS and Android, Fixed at $3,460, with the quote agreed before we start.