Most MVP advice is about what to put in the first version. That matters, but it skips the expensive part. The point of an MVP is to learn something, and if it works, what you learn is that the product needs to change. The first version is the cheap part. The second, third and fourth are where founders run out of money and time.
So the most useful question when you choose who builds your MVP is not what version one will cost. It is what happens the week after launch, when you know what to change.
In this article
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
The Short Answer
- You can test the idea without software: do that first, with a landing page, a video or a manual version of the service.
- The scope is fixed and you need a team to hit a date: an MVP development agency, with budget set aside for changes after launch.
- The job is small and you can manage a developer yourself: a freelancer, by milestone, with the code in your repository.
- You expect to change course after launch and you have no technical cofounder: a development subscription, so each change is another request rather than another quote.
Our guide to outsourcing product development covers all six ways to get software built. This post applies it to the most common first purchase, the MVP.
What an MVP Actually Is
Eric Ries, in a 2009 guide on his blog, defined the minimum viable product as "that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort."
The key word is learning. An MVP is not a small version of your finished product, and it is not a demo for investors. It is an experiment, and its job is to answer one question about your customers as cheaply as possible.
That has a practical consequence. If your MVP plan has a long feature list, it is probably a version one of the full product, and it will take months to build and teach you little until it ships.
The Best MVPs Had Almost No Code
Dropbox is the classic example. Drew Houston made a short video showing how the product would work. In Eric Ries's account of the story in TechCrunch, Houston says the video "drove hundreds of thousands of people to the website" and that the beta waiting list "went from 5,000 people to 75,000 people literally overnight." The video tested demand. The software could follow.
Zappos started even more simply. Nick Swinmurn told Fortune that his pitch to shoe stores was: "I'll take some pictures, put your shoes online, and if people buy them, I'll buy them from you at full price." No warehouse and no inventory, just a test of whether people would buy shoes online.
Neither of these is a reason to avoid software. They are a reminder of what an MVP is for. If a video, a landing page or a manual process can tell you whether people want the thing, it will tell you faster and for less. Build software when the question you need answered can only be answered by people using it.
Why the Second Version Matters More Than the First
In March 2026, CB Insights analyzed 431 venture-backed companies that had shut down since 2023. Running out of capital topped the list at 70 percent, but the report calls it "almost always the final cause of death, not the root problem." Behind it sit poor product-market fit at 43 percent, bad timing at 29 percent and unsustainable unit economics at 19 percent.
Poor product-market fit is exactly what an MVP exists to detect early, and the two numbers are easy to connect: an MVP that needs more versions than the budget allowed for runs out of money before it finds fit. Y Combinator's Michael Seibel describes the MVP's role plainly: "You should have an MVP, very small. All this is is a base to iterate from. That's it. It's just a starting point."
An MVP is a bet that you are partly wrong and want to find out where. Suppose it works: users sign up, use one feature heavily, ignore two others, and ask for something you never planned. You now know what version two should be, and you want it in weeks, not after a new round of proposals.
Pick the builder for the loop, not the launch. The first version is the cheap part.
That is why the way you pay for development matters so much at this stage. A model where change is expensive is the wrong model for the one project whose purpose is to tell you what to change.
Four Ways to Get an MVP Built
1. Build it yourself with no-code tools
Tools like Bubble, Softr or Glide let a non-technical founder build a working product without writing code. It is the cheapest way to start and often good enough to test demand. The limits arrive later: performance, complex logic, integrations and hiring, because a no-code app usually has to be rebuilt in code once it outgrows the platform. Treat it as a test, not a foundation.
2. Hire a freelancer
A single developer, by the hour or by milestone. It can be fast and affordable for a small, clear scope, and you keep close control. You also carry all the management: writing the spec, reviewing the work and deciding what comes next. Continuity is the risk. If the freelancer takes other work after launch, version two starts with someone new learning the code.
3. Hire an MVP development agency
An agency usually runs a discovery phase, quotes a fixed price for a defined scope, builds it with a small team and hands it over at launch. You get a project manager, design and development under one contract, and a firm price for version one. The structure is the catch. The quote covers one version, so the changes you learn you need after launch become new scope, new estimates and new invoices, at exactly the moment speed matters most.
4. Use a development subscription
A flat monthly fee for a queue of requests, worked one at a time by a senior developer, with the freedom to pause or cancel between months. Version one is a series of requests, and so is everything after it. When users tell you what to change, the change goes into the queue at no extra cost. It is not built for a large scope that needs several developers at once.
What MVP Development Costs
You will find plenty of price ranges for MVPs online. Most are averages across projects so different that the number tells you little about yours. Three things actually decide the cost.
How much you build before you learn anything. Every feature in version one that users ignore is money spent on the wrong thing. Cutting the scope to one workflow is the biggest saving available, and it costs nothing.
How many versions it takes to get it right. This is the number most budgets leave out. If you plan for one version and need four, you have planned for a quarter of the cost.
How each model charges for change. Hourly models bill every change as more hours. Fixed-price projects charge for change as new scope. A subscription absorbs change into the same flat fee and pays for it in time instead.
So when you compare quotes, ask every option the same question: what will version two cost, and how quickly can it start?
How to Choose an MVP Development Agency
If an agency is the right fit, these are the questions that separate a good one from an expensive one.
Ask before you sign
- What happens after launch? Is there a plan and a price for the changes you will need, or does the contract end at handover?
- How are changes priced during the build? Read the change-order terms, not just the quote.
- Will they cut features? A good MVP partner argues for less. One that accepts every feature on your list is pricing a full product.
- Who owns the code, and where does it live? It should be in a repository in your account from the first commit, with a written assignment of rights in the contract.
- How often will you see working software? Weekly, at least. A status report is not a demo.
- Who will actually build it? Ask whether the people on the sales call are the people writing the code.
The ownership point matters with any builder, not just agencies. Our outsourcing guide explains why code written by a contractor is not automatically yours under US copyright law.
Want your MVP built, and version two after it?
A senior developer on subscription: $849 a month, as many requests as you like, most shipped within 48 to 72 hours, and your money back if the first 7 days don’t prove it.
How to Build an MVP Without a Technical Cofounder
- 1
Write down the riskiest assumption
Not the feature list. The one belief that, if wrong, kills the idea. Usually it is whether a specific kind of customer has the problem badly enough to change what they do.
- 2
Find the cheapest test of it
A landing page with a sign-up, a short video, a manual version of the service, or a few customer conversations. If a test without code can answer the question, run it first.
- 3
Cut the build to one workflow
The one path through the product that tests the assumption: sign up, do the thing, get the result. Everything else goes on a later list.
- 4
Set up ownership before any code
A repository in your account, hosting and domains in your company's name, and a written assignment of rights from whoever builds it.
- 5
Launch to real users in weeks
Y Combinator's Michael Seibel puts it bluntly: "launch something bad, quickly." He suggests asking what you could launch in three weeks, because then "the only things that could be on my spec are things I can build in three weeks."
- 6
Budget for the loop
Plan for several rounds of changes after launch, and choose a builder who can make them quickly. This is where an MVP becomes a product, or tells you to stop.
Which Option to Pick
Cheapest and fastest for a first test. Expect to rebuild in code if it works, and do not let the platform's limits decide what your product becomes.
You get a firm price for version one and a team working in parallel. Agree the price of changes after launch before you sign, or that is where the budget goes.
Version one and every change after it come from the same queue at the same flat price, so learning what to change does not trigger a new quote.
Where a Development Subscription Fits, and Where It Doesn't
We run a product development subscription, so weigh this section accordingly.
It fits a founder building a web product who expects the plan to change once real users arrive, and who wants one senior developer to build version one and keep going. Requests are worked one at a time, so the MVP arrives as a series of working pieces rather than one reveal at the end, and the changes after launch cost nothing extra.
It does not fit everything. We do not build native mobile apps. A large MVP that needs several developers in parallel to hit a fixed date is better served by a team. And if the idea can be tested without code, you should test it that way first, and we would tell you so.
The Bottom Line
An MVP is an experiment, and the result of a good experiment is a list of things to change. Most founders choose who builds their MVP by comparing quotes for version one, then discover that version two is where the real cost sits.
Cut the first version to the one workflow that tests your riskiest assumption. Keep the code in your own repository. And choose a builder by asking one question: when we learn what to change, how fast and at what cost can you change it?
