Building the smallest thing that answers the question
An MVP is the smallest software that tests a specific uncertainty: will people use this, and will they pay. It is defined by the question rather than by feature count, and if you cannot state the question, the project is not an MVP. It is a first version.
MVP has become a synonym for a cheap first release, which loses what made it useful. The point is not that it is small; it is that it is an experiment with a stated hypothesis and a result that would change what you do next. A small build with no question attached is just a small build.
Scope grows because every feature seems necessary to test properly, and the result is a nine-month MVP that is a product launch with a humble name. Meanwhile no success criterion was agreed, so when it launches nobody can say whether the hypothesis was confirmed. The numbers are interpreted according to whoever most wants to continue. And no instrumentation was built, so even the basic behaviour is invisible.
When this work makes sense
Questions worth asking any supplier
What is the uncertainty? If everyone already knows people want this, you are building, not testing.
What result would make you stop? An experiment with no failure condition is not one.
What is the smallest thing that answers it? Usually smaller than the first proposal.
Is it instrumented? An MVP that cannot be measured produces opinions rather than evidence.
Who are the first users, and are they already reachable?
Deliverables
A written hypothesis with success and failure criteria agreed before building
The smallest build that tests it, with features excluded deliberately and listed
Instrumentation for the behaviour that constitutes evidence
Onboarding sufficient for real users, since a confusing MVP tests the wrong thing
A feedback channel so qualitative signal is captured alongside numbers
A launch plan naming the first users specifically
An honest readout against the criteria, including when the answer is no
A recommendation on what to build, change or stop
Built with
Process
The success criteria are written and agreed before any code, and they include what result would mean stopping. Without a failure condition agreed in advance, every outcome gets interpreted as encouraging by whoever is most invested. Writing it down while nobody is attached to the answer is the only point at which that judgement can be made honestly.
The standard nine stages, discovery, strategy, UX/UI, development, content and SEO, testing, launch, measurement and continuous improvement, apply to every project. The paragraph above is what differs for this one.
What moves the number
Pricing depends on scope, functionality, integrations and content requirements. These are the factors that change it most:
Prototype, MVP, or first version
Prototype
Fits: Testing whether people understand and want the concept
Limits: Not real software; cannot test willingness to pay or sustained use
MVP
Fits: Testing whether people will use and pay for it in reality
Limits: Deliberately incomplete, which requires honesty with early users
First version
Fits: Validated needs where the question is execution rather than demand
Limits: Larger investment before any market feedback
Case studies
No published MVP case study. Early-stage products are commercially sensitive and many are not public.
MBGDesk operates from 4 offices in India, United States, United Kingdom, United Arab Emirates. We hold no industry certifications and do not imply otherwise.
Frequently asked questions
How small should an MVP be?
Small enough to build quickly and complete enough that a real user can achieve the core outcome. If someone cannot get value from it, it tests whether people tolerate unfinished software rather than whether they want the thing.
Do we need to charge for it?
If willingness to pay is the uncertainty, yes. Enthusiasm for free software tells you very little. Many MVPs confirm that people like an idea and never test the only question that determines whether there is a business.
How long should it take?
Weeks rather than months for most propositions. If the scope requires nine months, either the hypothesis is too broad or the project is a first version. Both are legitimate; calling the second an MVP is what causes the problem.
What if the MVP fails?
Then it has done its job at a fraction of the cost of finding out later. That is the outcome the exercise exists to make cheap, and it is uncomfortable enough that the failure criteria have to be agreed in advance to be believed afterwards.
Should we tell users it is an MVP?
Be honest about it being early without using it as a blanket excuse. Users forgive missing features and are far less forgiving of things that appear to work and do not. Setting expectations also produces better feedback.
Can we build on the MVP afterwards?
Sometimes, and it should not be assumed. Code written for speed carries decisions that do not survive scale. We flag which parts are disposable at the time rather than pretending everything is production-grade.
What if we already know people want it?
Then build the product. An MVP tests uncertainty, and if there is none the exercise adds delay without adding information. The honest question is whether you know it or believe it, and customers who have asked for it are different from a team that is confident.
Services that connect to this
Talk to us about this
Tell us what you are trying to build and we will come back with scope, approach and an estimate.