Key takeaways
- An MVP is the smallest version of a product that tests one real assumption with paying or active users. It is not a stripped-down demo.
- A typical founder's first feature list runs to 30 or 40 items. A shippable MVP usually ships with 6 to 10 of them.
- Meant scopes MVPs as a fixed-price, fixed-scope build after a free 30-minute call, with projects starting at $2,000.
- An MVP is not a prototype. A prototype tests whether people understand the idea. An MVP tests whether they will use it and pay for it.
- Features that do not touch the core assumption, such as admin dashboards, multi-language support or loyalty points, almost always wait for version two.
What Is an MVP in App Development?
What an MVP is in app development comes down to one job: it is the smallest working product that tells you whether a specific assumption about your customers is true. At Meant, that is the test we apply to every feature on a founder's list. If a feature does not help answer the question, it does not belong in the first build.
The term comes from Eric Ries and the Lean Startup method. He defines the minimum viable product as the version of a new product that lets a team collect the maximum amount of validated learning about customers with the least effort. The word that matters there is "learning", not "minimum".
That corrects the most common misreading. Founders hear "MVP" and think it means a cheap app, a half-finished app, or a rough draft to show investors. Ries says plainly that an MVP is not about creating minimal products, and that building one adds overhead, because the team has to learn something real from the first release. A buggy app teaches you nothing except that people dislike bugs.
The answer is the same if you are asking what an MVP is in mobile app development. The platform changes the build. It does not change the purpose. Whether we ship it through bespoke website and app development in Next.js or as a native app, the MVP has to work properly, look credible and do one thing well enough that real people use it.
MVP vs Prototype vs Pilot: Where Founders Mix Them Up
These three words get used as if they mean the same thing. They don't. Each one answers a different question for a different audience, and mixing them up is how founders end up paying for the wrong thing.
A prototype tests understanding, not behaviour
A prototype is a clickable mock-up or a rough build. You put it in front of people to see whether they understand the idea and can find their way around it. It answers questions like "Does this flow make sense?" and "Can someone complete the task without help?"
It cannot tell you whether anyone will come back tomorrow, because nobody is relying on it. Productboard draws the same line: unlike a prototype, an MVP is not only used to test design or technical feasibility.
A pilot tests operations at small scale
A pilot runs a near-complete product, or a service, with a limited group, often one client, one region or one team. The question is operational. Can we deliver this reliably? What breaks when real volume arrives? Pilots suit businesses that already know there is demand and need to prove they can serve it.
An MVP tests whether people act
An MVP goes to real users who sign up, pay, book or return. Productboard calls it the fastest way to get through the Build-Measure-Learn loop with the minimum amount of effort and risk. Its output is behaviour, not opinion.
| Prototype | Pilot | MVP | |
|---|---|---|---|
| Question it answers | Do people understand it? | Can we deliver it reliably? | Will people use it and pay? |
| Who sees it | Test users, investors | One client, team or region | Real customers in the market |
| Working code | Often none, or partial | Yes, near complete | Yes, focused on one job |
| What you measure | Comprehension, task completion | Errors, delivery time, cost to serve | Sign-ups, payments, retention |
| Typical next step | Revise the design | Scale the operation | Build version two or change direction |
The 40-Feature List Problem
Most founders arrive with a long document. Login, profiles, a dashboard, notifications, an admin panel, referrals, analytics, two languages, a loyalty scheme. Thirty or forty items, each of them reasonable.
Why founders list everything the end product might need
Founders list everything because they can see the finished product clearly, and every gap feels like a reason someone might not buy. Competitors have features, so the list copies them. Investors ask questions, so the list grows to answer them. Somebody on the team mentions Arabic, so bilingual goes on the list too.
None of that is wrong as a roadmap. It is wrong as a first build. A good MVP scope starts from the question the product has to answer, not from the product you hope to own in three years.
What an over-scoped MVP actually delays
Every extra feature costs more than its own build time. It needs designing, testing, and fixing when it interacts badly with something else. It widens the gap before launch, and launch is the only point at which you start learning.
The bigger cost is clarity. Ship 40 features and get weak results, and you cannot tell which part failed. Ship eight around a single assumption, and the result means something. An over-scoped MVP delays your launch, and it also delays the answer you built it to get.
The Cut-List Exercise: From 40 Features to an Eight-Week Build
This is the method we use to turn a wish list into something that can ship. It works on paper before any code is written, which is when cutting costs nothing.
Step 1: Write down the one assumption the MVP must test
Write one sentence. For example: "Founders will enter their real numbers into a self-serve tool if it gives them a useful read on their runway." Or: "Clinic owners will pay monthly for online booking that syncs to their calendar."
If you can't write it in one sentence, the product isn't ready to scope yet. That is a positioning problem, and it needs sorting out first.
Step 2: Mark every feature that assumption depends on
Go down the list and ask, for each item, whether the test fails without it. For the booking example, a customer must be able to see open slots, book one, and get a confirmation, and the clinic must see the booking. Payment probably stays in, because "will pay" is part of the assumption.
Mark those items. On a 40-item list, this usually leaves somewhere between 6 and 10.
Step 3: Cut anything that only supports scale, not proof
Some features matter once you have thousands of users and mean nothing with fifty. These include role-based admin panels, bulk exports, advanced reporting, referral schemes and multi-currency billing. For the first cohort, a spreadsheet, a manual email or a direct database view does the job.
Cut them, but write them down. The cut list becomes the first draft of version two.
Step 4: Price and schedule what is left
Only now do we put a price and a timeline on it. A focused set of features can be designed, built and tested in a fixed window, and the price can be fixed in writing. If the number is too high, you go back to Step 2 and cut harder. You don't let the scope stay vague.
If you want to see how the agreed scope turns into a commitment, here is what's inside a fixed-price build contract.
What Stays In and What Waits for Version Two
The examples below are general patterns, not rules. The test from Step 2 always decides.
Features that usually make the cut
The core action. Whatever the user came to do has to work end to end: booking, buying, calculating, submitting. You also need just enough account handling to support that action. Many MVPs start with email sign-in or no account at all.
You need a way to measure the result, so you can see who did the thing and whether they came back. And if the assumption includes "will pay", payment goes in.
A single, well-built flow can carry a whole product. Nimbus Finance's CFO diagnostic flow is a good illustration. Three sliders drive a runway gauge, a health score and a CFO-style read, and the experience is built around that one interaction.
Features that almost always wait
- Admin dashboards beyond the bare minimum
- Multi-language support, unless the assumption is about a bilingual market
- Loyalty points, referrals and gamification
- Native apps on both platforms at once
- Advanced analytics and custom reporting
- Integrations with tools the first users don't need
Extra layers work best when they sit on top of something that already works. Grumpus's AI layer, added on top of its full rebrand and rebuild, shows the shape. The brand and the full-stack site are the foundation, and the Telegram AI character, with conversation memory, football predictions and community polls, sits as a separate layer above it.
| Feature | MVP | Version two |
|---|---|---|
| Core user action, end to end | In | |
| Basic sign-in or guest access | In | |
| Payment (if testing willingness to pay) | In | |
| Event tracking for the core action | In | |
| Full admin dashboard | Waits | |
| Multi-language support | Waits, unless it is the assumption | |
| Loyalty points and referrals | Waits | |
| Both iOS and Android native apps | Waits | |
| Custom reporting | Waits | |
| AI features beyond the core job | Waits, unless it is the assumption |
How Long an MVP Should Take and What It Should Cost
Once the scope is cut properly, the timeline and price follow from it. They should both be known before work starts.
Why eight weeks is a realistic target for a focused scope
Six to ten features, one clear user journey and one assumption fit comfortably into roughly eight weeks of design, build and testing. That leaves time to do the work properly without dragging the launch out.
Eight weeks is a target, not a promise. Complex payments, regulated data or third-party integrations add time. If a scope needs much longer than eight weeks, that usually tells you the cut list exercise has not finished yet.
How fixed-price quoting changes the incentive to over-scope
With hourly billing, nobody is penalised for adding features. The studio bills more and the founder finds out at the end. A fixed price reverses that. Every feature has a visible cost before anyone commits, so both sides have a reason to keep the scope tight.
Our rules are simple. Projects start at $2,000. Builds are fixed scope and fixed price, agreed in writing after a free 30-minute call. See how fixed-price quoting after a free call works in practice. If you need ongoing automation or marketing after launch, that runs as a monthly retainer you can stop at any time.
We are not the right fit for everyone. If you want a large team building a 40-feature platform from day one, a bigger agency will suit you better. We work best with founders who want to launch small, measure and then grow.
Frequently asked questions
How much does an MVP app cost to build?
The cost depends on the scope, which is why we cut the scope before we quote. Our projects start at $2,000, and every build is quoted at a fixed price in writing after a free 30-minute call. A tightly scoped MVP will always cost less than one that tries to cover the full roadmap.
How is an MVP different from a beta version?
A beta is a near-finished product released to find bugs and rough edges before a wider launch. An MVP is a focused product released to test whether a core assumption about customers is true. A beta asks whether the product works. An MVP asks whether anyone wants it.
Should an MVP launch as a native app or a web app first?
For most MVPs, a web app is the faster and cheaper way to test the assumption. It runs on any device, ships without app store review and can be changed the same day. Go native first only if the assumption depends on device features such as offline use, push notifications or deep camera access.
How do you know if an MVP has proven its assumption?
Before launch, decide what result counts as proof. That might be a number of paid sign-ups, a return rate or completed bookings within a set period. Then measure the real behaviour against it. If you set the bar after launch, every result will look like success.
What typically gets built after the MVP succeeds?
Usually the cut list, reordered by what the first users asked for and what scale now demands. That often means admin tools, reporting, extra languages, integrations and sometimes a native app. The MVP data decides the order, not the original wish list.
If you have a feature list and need it cut down to something you can ship in weeks, book the free 30-minute call with Meant and we'll scope it together.
