How to do it
Separate the MVP from the product
An MVP is the smallest thing that tests one assumption with real users. It is not a small version of the eventual product. Most quotes are high because the brief describes the product — roles, settings, billing, an admin panel — none of which tests anything.
Price the drivers, not the features
Three things move the number more than anything else: how many external systems you integrate with, how many distinct user roles exist, and whether you handle money or regulated data. A single-role tool with no integrations and no payments is a different order of cost from anything else.
Decide who builds it before you budget
Yourself, a freelance pair, or an agency. The gap between the cheapest and most expensive credible route is roughly six times, and the deciding factor is usually how much of the specification you can write yourself — a vague brief is the single most expensive thing a founder brings to a quote.
Ask whether you need to build at all yet
The cheapest MVP is the one you do not write. If the assumption you are testing is 'will anyone pay', a landing page and a manual delivery test answer it for a few thousand rupees. Build when the open question is one that only working software can answer.
Worked example
Scope, not rate, is what moves the quote
Founders negotiate hourly rates and accept scope. It is the wrong way round. The difference between a good and a cheap developer is perhaps thirty percent; the difference between one user role and three is closer to double.
Before comparing quotes, cut the brief: remove the admin panel, remove the second role, remove settings nobody has asked for, and push every integration past the first into version two. A brief that fits on one page usually costs half what the same idea costs when it fits on five.
The budget line founders forget
Almost every first-time budget covers the build and nothing else. The money then runs out during distribution, which is where the business actually gets decided.
A workable split is roughly half the available money on building and half on finding out whether anyone wants it. Founders who spend everything on the product arrive at launch with a working thing, no audience, and no runway to find one.
What goes wrong
- Briefing the product instead of the experiment, then being surprised by the quote
- Adding an admin panel to version one, which nobody outside the team will ever open
- Paying to build before finding anyone who has paid to solve the problem some other way
- Comparing quotes on price without comparing what each one included
- Budgeting the build and nothing for distribution, which is where the money actually runs out
Is your number plausible?
Each check catches a different way the arithmetic can be right and the answer still wrong.
- If the MVP takes more than about twelve weeks, it is not an MVP — find the assumption you can test in four
- Count the user roles in the brief. More than one in version one usually means the scope grew past the experiment
- If you cannot say in one sentence what the build would prove, do not commission it yet
Related answers
Can I build it with no-code?
Often yes, for a first version. No-code shifts cost from money to constraints: fast to build, cheaper to change early, harder to scale and to customise later. For testing whether anyone wants the thing, that trade is usually right.
How do I compare two quotes fairly?
Ask both to price the same one-page brief, and ask each what they would cut to halve it. The second answer tells you more than the first — a good team will name the scope that is not testing anything.
What does a fair milestone schedule look like?
Payments tied to working software you can open, not to phases like "design complete". Three to four milestones over eight to ten weeks, with the first one small enough that walking away costs you little if the working relationship is wrong.