A minimum viable product, or MVP, is the smallest version of a product that allows a startup to test a specific assumption about customer demand with real users. The purpose of an MVP is not to ship a smaller version of the eventual product; it is to learn, as cheaply and quickly as possible, whether the core assumption behind the business is correct before investing further time and capital in building it out.
Founders who have not yet completed basic idea validation should do so before beginning MVP development, since building a product around an unvalidated assumption simply delays the discovery that the assumption was wrong.
What exactly should an MVP test?
Before writing any code or commissioning any design, founders should write down the single riskiest assumption in the business. Common examples include: will a specific customer segment pay for this solution; will they switch from their current method; will they use the product repeatedly rather than once. The MVP should be built specifically to test this assumption, and nothing more. Features that do not help answer this question should be deferred, regardless of how appealing they seem.
How small can an MVP actually be?
Many founders overestimate how much needs to be built before testing demand. In several cases, a manual process, a simple form, a WhatsApp-based service, or a basic landing page with a waitlist can validate demand before any software is written. This approach, sometimes called a concierge MVP, substitutes founder effort for automation in the earliest stage, which is acceptable because the goal at this point is learning, not operational efficiency.
Only once there is evidence that customers want the outcome should founders invest in automating the experience. This sequencing also supports a lower-cost path toward product-market fit, since capital is not spent building features for a product that does not yet have demonstrated demand.
HYPOTHETICAL example: testing demand before building software
The following example is illustrative only. Assume two founders have an idea for a service that helps small clinics manage patient appointment reminders by SMS. Rather than building a full appointment system, they first approach 15 clinics directly and offer to manually send reminders for a trial fee of ₹1,500 per month using a simple spreadsheet and a bulk SMS tool.
Of the 15 clinics approached, 6 agree to pay, generating ₹9,000 in monthly revenue (6 x ₹1,500) before any software has been built. The founders spend approximately ₹6,000 on the bulk SMS service and basic tools, leaving a early gross margin of roughly ₹3,000 for the month, excluding their own time. More importantly, 4 of the 6 clinics ask whether the service can also confirm appointments automatically, which becomes the first real feature specification for the software MVP, based on actual customer requests rather than founder assumption.
Build, no-code, or outsource: how should founders decide?
The right build approach depends on technical skill in the founding team, the complexity of the core assumption being tested, and available budget.
| Approach | Best suited to | Caution |
|---|---|---|
| Manual or concierge MVP | Testing willingness to pay before building anything | Does not scale, but fastest to learn |
| No-code or low-code tools | Simple workflows, forms, basic marketplaces | May need rebuilding once validated |
| In-house technical build | Founding team includes a technical co-founder | Slower if team is small or inexperienced |
| Outsourced development | Non-technical founders, well-defined scope | Requires clear specification and careful vendor selection |
MVP scope checklist
Before committing to a build, founders should confirm the following:
- The single assumption the MVP is meant to test is written down clearly
- Every proposed feature is checked against whether it is needed to test that assumption
- A manual or low-cost alternative has been considered before committing to a technical build
- A small number of real target customers have agreed to test the MVP, not only friends or family
- A method exists to collect feedback and usage data once the MVP is live
- A rough budget and timeline have been set, with a decision point to stop or pivot if results are poor
How does MVP development connect to pricing and go-to-market?
An MVP is also the first opportunity to test pricing, since a customer who will not pay even a modest amount often signals weaker demand than one who readily agrees. Founders should review guidance on B2B pricing in India and begin thinking about a simple go-to-market approach even at this early stage, since the way the MVP is sold often becomes the basis for the channel used later. A small number of paid pilots can be run directly from the MVP stage.
How do investors view MVP-stage companies?
Investors generally do not expect a fully built product at the pre-seed stage, but they do expect evidence that the MVP has been tested with real customers and that the founders have learnt something specific from it. This evidence forms an early part of investor readiness and is commonly requested as part of the documents investors require before a seed round. Vague claims of interest without evidence of actual usage or payment are usually treated with caution during due diligence.
How RaiseMoney supports MVP development
Product development, including MVP scoping and testing, forms one of the eight pillars of the RaiseMoney incubation programme. Founders receive mentor guidance on scoping the smallest viable test, choosing a build approach suited to their resources, and translating early usage data into a credible case for the next funding stage. Founders at idea or early MVP stage can apply to the programme.
Sources
Startup India, official Government of India portal, reviewed 4 October 2026.
This guide is for general educational purposes and does not constitute business, legal or financial advice. Founders should consult a qualified professional before making decisions specific to their business.
To get structured support in scoping and testing an MVP, founders can apply to RaiseMoney's incubation programme.
Frequently asked questions
What does MVP mean for a startup?
MVP stands for minimum viable product: the smallest version of a product built specifically to test a key assumption about customer demand, rather than a scaled-down version of the final product.
Do I need to write code to build an MVP?
Not necessarily. Many assumptions can be tested with a manual process, a simple form, a landing page, or a no-code tool before any software is written. Coding should follow, not precede, evidence of demand.
How do I know if my MVP has proven demand?
Look for concrete signals such as customers paying, returning to use the product again, or referring others, rather than polite interest or positive verbal feedback alone, which is a weaker indicator of real demand.
How much should an MVP cost to build?
There is no fixed figure, since it depends on the assumption being tested, but founders should aim to spend the minimum necessary to get a credible test in front of real customers, often starting with manual or low-code approaches before a full technical build.
What is a concierge MVP?
A concierge MVP is a version of a product where the founders manually perform the service behind the scenes for early customers, rather than automating it, allowing them to learn what customers actually need before building software.
Do investors expect a finished product at the MVP stage?
No. Investors generally expect evidence that the MVP has been tested with real customers and that specific learning has resulted, rather than a fully built or polished product at this early stage.