How much does it cost to build an MVP?
The honest answer: it depends on scope, not on 'an MVP'
There is no standard price for an MVP, because 'MVP' describes an intention — the smallest product that tells you whether people want this — not a fixed amount of software. Two products that both get called an MVP can differ by a factor of ten in effort.
What moves the price is the number of distinct things a user can do, how many other systems the product has to talk to, how many platforms it ships on, and how much of it must be correct on day one (payments and permissions cost more than a landing page). Ask any vendor for a number before those are written down and you are getting a guess.
Two ways to pay for it
A fixed-scope build gives you one price, one date and one deliverable. It suits a well-understood product, because the scope is written down and agreed before work starts. At VA Org these start from $12k, and the written scope is where we confirm the real figure for your product.
A dedicated team is paid monthly instead — from $6k per developer per month for us — and suits work where the scope will keep moving. You get senior engineers working your board and your standups, and you can scale the team up or down with 30 days' notice.
How to make an MVP cheaper without making it worse
Cut features, not quality. List everything you want, then keep only what a first real user needs to get the job done once. Everything else is a second release.
Ship on one platform first unless the product genuinely depends on being on two. Use proven building blocks for the boring parts, like sign-in and billing, and spend your budget on the one thing that makes your product different.
Finally, insist on seeing working software early. A live URL in the first week and a clickable demo every couple of weeks means you find out what's wrong while changing it is still cheap.
What to ask before you sign
Ask what is in the price and what is not, who owns the code from the first commit, what happens after launch, and what the vendor will do if the scope turns out to be wrong. A good answer to the last one is a plain description of how changes are re-scoped in writing — not a shrug.