On this page
The MVP development process is how you get from an untested idea to a small working product that real people use. The aim is to spend as little as possible to learn whether the idea holds. We run it in six steps: find the riskiest assumption, define success, draw the scope line, choose the build approach, build in short cycles, then test, launch and decide. Each step below ends with the deliverable you should have in hand before you move on.
It is the same process behind our MVP software development services, written so you can run it with your own team. When Thanos Gkanas, our Head of Engineering, leads the build, steps 1 to 4 make up our Audit, step 5 is the Build and step 6 is the Ship. Further down you will find MVP testing methods, minimum viable product examples worth learning from and the failure modes that stretch a build.
What is MVP in software development?
In software development, an MVP, or minimum viable product, is the smallest working version of a product that lets you learn whether real users want it. Eric Ries, who popularized the term, defined it in a 2009 guide. His definition: the version of a new product that lets a team collect the most validated learning about customers for the least effort. In practice that usually means one core workflow, built properly, for one kind of user.
What is minimum viable product thinking, beyond the definition? It treats the product as an experiment. "Minimum" means the smallest scope that can test your riskiest assumption. "Viable" means it works well enough that if people walk away, you learn something about the idea and not about your bugs. An MVP is not a buggy version of the full product, and it is not a demo.
MVP, prototype and proof of concept
Founders often use these words interchangeably, but each one answers a different question and treats its code differently.
| Question | Proof of concept | Prototype | MVP |
|---|---|---|---|
| What it tests | Can this be built? | Do people understand and want this design? | Will people use it, and pay for it? |
| Who sees it | The team | Test users in sessions | Real users in their own setting |
| What it looks like | A technical spike, often with no interface | A clickable design or a throwaway build | A small working product |
| What happens to the code | Usually discarded | Expected to be thrown away | Kept and grown, so it needs tests |
The difference that matters most to engineers is the last row. The GOV.UK Service Manual tells teams to expect to throw away the code from their alpha prototypes. An MVP is the opposite: the code you build is the code you grow, so it needs tests, a sensible structure and accounts you own from the first week.
The MVP development process in six steps
1. Find the riskiest assumption
Every idea rests on a few things that must be true. People have the problem, they will try a new way to solve it, they will pay, and you can reach them. Write those assumptions down and mark the one most likely to be wrong. If it is about demand rather than technology, you may not need code yet. Our guide on how to validate a product idea covers interviews, smoke tests and pre-sales. If you are still unsure which problem to solve, work through a product discovery framework first.
Deliverable: a ranked list of assumptions, with the riskiest one marked as the thing the MVP will test.
2. Define success before you write code
Write a one-paragraph brief. Name who the user is, the one job the product does for them, the metric that shows it worked and the threshold that would make you continue. Set a decision date as well. For example, a seed-stage team building a scheduling tool for clinics might set this rule. It continues if a third of its pilot clinics book appointments in a second week without a reminder from the team.
Deliverable: the MVP brief, with the success metric, threshold and decision date agreed by everyone who will make the call.
3. Draw the scope line
List every feature anyone has suggested, then draw a line. Above it go only the features needed to complete the core job and to measure whether it worked. Everything else goes below the line, with a note on what evidence would move it up. Our scope planner helps with MVP feature prioritization if you want a structured first pass.
These usually fall below the line: admin panels (use the database console or a spreadsheet at first), complex roles and permissions, and settings pages. So do integrations beyond the first, and native mobile apps when a web app can test the idea.
Deliverable: a feature list with the scope line drawn and a time estimate for everything above it.
4. Choose the build approach
Not every MVP needs custom code. A concierge MVP delivers the outcome by hand for a few customers. A no-code build can test a simple workflow. Custom code makes sense when the core workflow is the product, when it handles sensitive data, or when you expect to grow it into the real thing.
If you build custom, keep the stack boring: one repository, one database, managed hosting and an established authentication provider. Open every account in the company's name from day one, including the code repository, the cloud account, the domain and the app stores. Apple, for example, requires organizations to have a D-U-N-S Number to enroll in its developer program, so start that paperwork early. Founders without an engineering partner often weigh technical co-founder equity against hiring help for this stage, and that decision is worth making before the build starts.
Deliverable: a one-page technical plan covering the approach, the stack, hosting, the accounts and who owns each one.
5. Build in short cycles
Ship a working build to a staging address every week and demo it to someone outside the team. Short cycles catch misunderstandings while they are still cheap. From the first week, add a CI pipeline that runs tests on the core workflow, error tracking, and the analytics events your success metric needs. Keep a short list of the shortcuts you take on purpose, so you can pay them back after launch.
Small is not the same as sloppy. Broken access control is first in the OWASP Top 10:2025, so make sure every endpoint checks who is asking before you invite outside users. If you collect personal information from people in Canada, federal privacy law such as PIPEDA can apply. Write a plain privacy notice and collect only what the MVP needs.
Deliverable: a deployed product, tests on the core workflow, analytics events that report your success metric and a written list of deliberate shortcuts.
6. Test, launch and decide
Put the product in front of real target users before any public launch. Then open it to a small group and watch the metric you chose in step 2. On the decision date, compare the result with the threshold and make one of three calls: build on it, change one thing and test again, or stop. Writing the rule down in step 2 is what keeps this step honest.
Deliverable: a written decision, with the evidence behind it.
MVP testing with real users
MVP testing happens in three layers, and each one catches problems the others miss.
- Usability sessions before launch. Ask a handful of people from your target group to complete the core task while you watch, without helping. Note where they hesitate, what they expected to happen and the words they use. Fix the worst problems, then run another round.
- A closed pilot with real data. Give a small group access in their own setting, with their own work. This is where reliability, onboarding gaps and missing features show up.
- An instrumented launch. Open the product to a wider group and measure behaviour rather than opinions.
For the measurement layer, Google researchers published the HEART framework in 2010: Happiness, Engagement, Adoption, Retention and Task success. Teams choose them by working from goals to signals to metrics. For most MVPs, three categories matter most. Adoption asks whether new users completed the core task. Retention asks whether they came back for a second use, and task success asks whether they could finish without help. The same paper points out that raw counts grow with your user base, so ratios and averages per user tell you more.
Numbers tell you what happened. Sessions and short follow-up calls tell you why. You need both before you decide.
Minimum viable product examples worth learning from
Good minimum viable product examples share one trait: each tested the riskiest assumption with far less than a full product. The first two are documented; the last two are hypothetical patterns.
- Dropbox, 2007. Drew Houston posted a short screencast of the product to Hacker News alongside his Y Combinator application. Commenters asked whether it beat USB drives or existing tools such as FTP and version control, and raised cost and trust concerns. A demo collected hard objections before the team built more features.
- Airbnb, 2007. Airbnb's own history says it began when two hosts welcomed three guests to their San Francisco home. The first test was small enough to run by hand, and it tested the core assumption: that guests would stay in a stranger's home.
- A concierge MVP. For example, a team exploring AI bookkeeping for small agencies might categorize transactions by hand for ten clients for a month. If clients stay and pay, the team knows what to automate first, and in what order.
- A single-workflow MVP. A B2B team might build only the report its buyers already assemble by hand in spreadsheets, with no dashboards or settings. If buyers use the report every week, the rest of the product has a reason to exist.
What slows an MVP build down
These are the failure modes we watch for, because each one adds weeks without adding learning.
- Scope that creeps back. Features return from below the line one small request at a time. Keep the list visible and make every addition replace something.
- Infrastructure before users. Weeks spent on microservices, custom admin tools or scaling plans for traffic that does not exist yet.
- No decision rule. Without the threshold from step 2, every result looks promising enough to keep building.
- Polish before evidence. Pixel-perfect screens for a workflow nobody has tested yet.
- Accounts in the wrong name. Code, hosting or app store listings owned by a freelancer or an agency, which turns every later change into a negotiation.
- No tests at all. The first weeks feel fast. A month later, every change breaks something else and the pace drops.
After the MVP: build on it or start again
If the MVP was built with tests, clear boundaries and accounts you own, build on it. Pay back the shortcuts you recorded in step 5, harden the parts that real usage put under stress, and draw the next scope line from what users actually did. Start again only if the evidence sent you somewhere new, or if the MVP turned out to be a prototype dressed up as a product. In that case, keep what you learned and rebuild the core workflow properly.
Frequently asked questions
What is an MVP in software development?
An MVP in software development is the smallest working version of a product that lets real users complete one core task. The team can then learn whether the idea works before building more. It is narrow but reliable: one workflow, built properly, with the measurements needed to decide what happens next.
How long does the MVP development process take?
It depends mostly on scope. Writing the brief and drawing the scope line takes days, not months. A tightly scoped MVP with one core workflow is usually a build of weeks rather than quarters. The reliable way to hold a date is to fix the timebox first and cut features until the core workflow fits inside it.
What are good examples of a minimum viable product?
Dropbox tested interest with a short demo screencast posted to Hacker News in 2007. Airbnb began in 2007 when two hosts welcomed three guests to their San Francisco home. Other common patterns are the concierge MVP, where the team delivers the result by hand, and a single-workflow product that does one job well.
What is the difference between an MVP, a prototype and a proof of concept?
A proof of concept checks whether something can be built, and its code is usually discarded. A prototype checks whether people understand and want a design, and it is also expected to be thrown away. An MVP is a small working product used by real people, and its code is kept and grown, so it needs tests.
How do you measure whether an MVP worked?
Compare the result with the success metric and threshold you set before the build. Most MVPs are judged on adoption (new users completing the core task), retention (users coming back) and task success (finishing without help). Pair the numbers with user sessions, then decide to build on it, change one thing and retest, or stop.
Sources and update history
- Eric Ries, Minimum Viable Product: a guide (August 3, 2009)
- GOV.UK Service Manual, How the alpha phase works
- Rodden, Hutchinson and Fu, Measuring the User Experience on a Large Scale (Google, CHI 2010)
- Hacker News, My YC app: Dropbox, Throw away your USB drive (April 4, 2007)
- Airbnb Newsroom, About us
- OWASP Top 10:2025
- Apple Developer, Enrolling as an organization
- Office of the Privacy Commissioner of Canada, PIPEDA requirements in brief
Update history
- First published.
