Definitions and costs
What an MVP is and what it costs to build
The acronym gets used for anything, from a slide deck to a finished product. Here we take it back to the original definition, explain what goes in and what stays out, and give the cost and time ranges we use in our quotes, with three examples from our own projects.
Written by Maximilian Giurastante. . 11 minute read.
An MVP (minimum viable product) is the smallest version of a product that lets you check with real users whether the problem exists and whether the solution solves it. It is not a demo and not a prototype: it is working software, built around a single main flow, released so you can learn from how people use it. Having one built usually costs between 5,000 and 15,000 euros and takes four to eight weeks.
In short
- The original definition comes from Eric Ries (2009): the version of a new product that lets a team collect the maximum amount of validated learning about customers with the least effort. The key word is learning, not minimum.
- An MVP is not a clickable prototype and not a demo: it is software that real people use. It is not the first complete version either: it holds a single main flow.
- According to CB Insights (March 2026), 43% of the startups that shut down since 2023 had a market fit problem; building less and checking sooner is the answer to that number.
- A working range for an MVP with one well defined flow: from 5,000 to 15,000 euros and four to eight weeks. What pushes it up is roles, payments, integrations and a mobile app.
- What goes in is decided on two axes: value to the user and cost to build. Features with high value and high cost are done by hand in the first version.
- Shipping is not the end: you measure for four to eight weeks (activation, return, willingness to pay) and then decide whether to extend, fix or stop.
The original definition, and what an MVP is not
The acronym was born in 2009 in the startup community and has since been stretched to mean any reduced version of anything. Going back to the original sentence pays off, because it holds a precise rule for deciding what to build.
The minimum viable product is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.
Three things in that sentence usually get forgotten. Validated learning: the point of an MVP is to learn something you did not know before, checking it with data and not with opinions. About customers: what you learn is how real people behave, not whether the code works. Maximum with the least: the least applies to the effort, not to the value; an MVP nobody needs is not minimal, it is useless.
Four things that get called an MVP and are not
| What it is | Why it is not an MVP | What it is good for instead |
|---|---|---|
| Clickable prototype | It does not work: it shows screens, it does not process data | Discussing the flow before writing code, in a week |
| Demo or slide deck | No real user runs their own work on it | Gathering interest or funding |
| First complete version | It holds everything you imagine is needed, before you know what is needed | Nothing: it is the most expensive way to find out you were wrong |
| Beta with every feature half done | Many things that work badly instead of one that works well | Losing your first users, who do not come back |
Why build less, with the numbers
MVPs exist because most products fail on the market and not on the technology. Startup data has said so for years, and the 2025 data on generative AI projects says the same thing in another sector.
- 43%
- of the startups that shut down since 2023 had a market fit problem (CB Insights, March 2026, on 431 funded companies)
- 42%
- of failures attributed to "no market need" in the historical post-mortem analysis (CB Insights, The Top 20 Reasons Startups Fail, 101 cases)
- 95%
- of organizations with no measurable return from their generative AI pilots (MIT NANDA, July 2025, preliminary results)
The two CB Insights figures come from different methods and should not be added together: the first looks at shutdowns since 2023, the second is a historical reading of 101 post-mortems written by founders. They do say the same thing: among the leading causes of failure is having built something that not enough people needed. The same analysis notes that "running out of cash" (70% in the recent cases) is almost always the last cause, not the first.
An MVP is the way to find that out before spending everything. It does not guarantee success: it guarantees that the discovery costs weeks instead of years. It is the same principle we apply to client projects, where the client has a clear idea of what they need but has not yet watched anyone use it.
What goes into the MVP and what stays out
The hard decision is not what to build but what to leave out. Two questions for every feature: how much is it worth to the user of the first version, and how much does it cost to build properly.
Where each feature goes
Two by two matrix. Horizontal axis: cost to build, from low to high. Vertical axis: value to the user of the first version, from low to high. High value and low cost: inside the MVP. High value and high cost: simulated by hand in the first version and built in the second. Low value and low cost: later, if someone asks. Low value and high cost: out.
- Cost to build: low / high. Value to the first user: low / high.
- Inside the MVP: this is the main flow: build it properly, ship it, measure it.
- Simulated by hand: in the first version a person does it behind the scenes; automate it in the second, if real use justifies the work.
- Later, if asked for: cheap to build but it does not change what the user decides: it goes in when someone asks for it.
- Out: expensive and it does not change the decision: take it off the list and stop talking about it.
The features we almost always postpone
- Fine grained roles and permissions. Two roles are enough in the first version. Detailed permissions arrive when there are enough users to need them.
- Several integrations with outside systems. Just one, the one the flow cannot work without. The others can be handled with an export.
- A native mobile app. A web application that works well on a phone covers the first version of almost anything.
- Dashboards and advanced reports. A spreadsheet export and a table are enough to learn what users want to see.
- Automatic payments. If the first customers are few, an invoice written by hand costs less than an integration, and you learn sooner what they are willing to pay.
What an MVP costs
The ranges below are the ones we use in our quotes and publish on our pricing page. They are not a price list: two MVPs described in the same words can cost twice as much as each other, and the variable that moves the number most is not the number of screens but the number of outside systems to connect.
| Type of MVP | Range | Time | What pushes it up |
|---|---|---|---|
| One main flow, users with a login, their own data | from 5,000 to 15,000 euros | four to eight weeks | User and role management, payments, integrations with existing business systems, a mobile app on top of the web one |
| Automating a process, with no complex interface | from 1,500 to 6,000 euros | one to three weeks | Number of systems to connect, volume of data, human review on every step |
| A full multi-tenant platform (no longer an MVP) | from 15,000 to 40,000 euros and up | three to six months | Data isolation between customers, subscriptions, admin panel, multiple languages |
The costs that stay on your side
- Managed hosting and database: from a few tens to a few hundred euros a month, depending on traffic. For an MVP, almost always at the low end.
- Third party services: email sending, payments, file storage, AI models if there are any. Paid by usage.
- Domain and certificates, if you do not already own them.
- The time of someone inside the company who knows the process and answers questions: this is the factor that most often decides whether a project runs smoothly.
For the ways of working together (fixed price project, working alongside your team, consulting), the full ranges and what maintenance covers, the page how we work and what it costs is the source of these figures. For how we run a product from analysis to release, see custom software development.
How long it takes, week by week
Eight weeks is the typical case for an MVP with one well defined main flow. The sequence below is the one we follow: the test with real users sits in the middle, not at the end.
Eight weeks, five phases
Timeline over eight weeks. Week 1: analysis and prototype of the flows. Weeks 2 to 5: building the main flow with weekly releases. Week 6: test with real users. Week 7: fixes from what came up. Week 8: release and start of the measurements.
- Analysis and flow prototype: Wk 1. what goes in, what stays out
- Building the main flow: Wk 2-5. a release every week
- Test with real users: Wk 6. five people are enough
- Fixes: Wk 7. from what came up
- Release and measurement: Wk 8. activation, return, payment
Week six is the one many people skip, and it is the one that justifies all the others. Five people using the software for their own work, watched while they do it, tell you more than a hundred answers to a questionnaire. The fixes in week seven come from there, not from the opinions of whoever commissioned the product.
Three examples from our own projects
Three products, three different MVPs: one built for the market, one for a client in a single week, one for a client with a fixed deadline and a scope split into three bands.
BYOURIT: the engine first, everything else later
BYOURIT analyses couple compatibility with a biorhythm calculation engine. The MVP was the engine plus one page: enter two dates, get a result, no sign up. Payments and full reports came after we saw that people were coming back. Had they not come back, the engine would have cost a fraction of the finished product.
Omnia Leads Manager: one week, three languages, one flow
The lead management system for a company with divisions in three countries was built between 18 and 24 June 2025: sign up with approval, contact records, import from the existing spreadsheets, search. The languages were in from day one because the market was; the email panel and the statistics arrived in the following weeks, when real use called for them.
SYNAPSE: a scope in three bands and a fixed deadline
For the platform that monitors a fleet of installations the deadline was fixed and only a few weeks from the start. The requirements were split into three bands before a line of code was written, and the first version held only the first band. Real time monitoring and alerts came later, once the technicians were already inside the tool. It is an MVP even though nobody called it that.
What happens after the release
An MVP that ships and is never measured is just another first version. The four to eight weeks after the release are there to answer three questions, and the answers decide the next step.
- Do people get to the result? Activation: how many of those who start the flow finish it. If they are few, the problem is in the flow and it gets fixed before anything else is added.
- Do they come back? Return after one week and after four. It is the most honest measure of value: nobody comes back to a tool they do not need, however good it looks.
- Would they pay, or do they pay? Willingness to pay, or a real payment if there is a price. A client MVP has a variant: would the client keep using it if they had to pay to run it every month?
- Decide: extend, fix, stop With the three answers you decide whether to build the second band, whether to redo part of the flow, or whether to stop having spent weeks instead of years. The third option is a win for the MVP, even if it does not look like one.
Frequently asked questions
What is the difference between an MVP and a prototype?
A prototype shows what the product will look like but does not work: clickable screens with no real data. An MVP works and is used by real people in their own work, even if it does one thing only. The prototype comes first, to discuss the flow in a week; the MVP is there to learn from real use.
How much does it cost to build an MVP in Italy?
An MVP with one well defined main flow, users with a login and their own data usually costs from 5,000 to 15,000 euros and takes four to eight weeks. The cost goes up with fine grained roles, payments, integrations with existing systems and a native mobile app. The real quote comes out of a free requirements analysis, because integrations are the deciding variable.
How long does an MVP take?
Four to eight weeks, in this sequence: one week of analysis and flow prototype, four of development with weekly releases, one of testing with real users, one of fixes, one of release and starting the measurements. Timelines stretch mostly when there is nobody inside the company to answer questions.
What should an MVP contain?
A single main flow, start to finish, for one type of user, built properly. Valuable features that cost a lot are done by hand behind the scenes in the first version. Fine grained roles, several integrations, native apps, advanced dashboards and automatic payments are almost always postponed; languages are not, if the market is multilingual from day one.
Do you throw the MVP code away afterwards?
No, not if it is built with the same rules as a product: tests on the main flow, well structured data, no shortcut that weakens security. An MVP built that way becomes the base of the second version. What gets thrown away are the features that real use has shown to be pointless, and that is a saving, not waste.
How do you measure whether an MVP worked?
With three questions in the four to eight weeks after the release: how many people complete the flow (activation), how many come back after one week and after four (return), how many pay or would pay. The answers decide whether to extend, fix a part or stop. Stopping after eight weeks instead of after two years is one of the possible results of a successful MVP.
Sources
The figures quoted in the text, each linked to the original document. Numbers are reported as published by the source, with the year they refer to.
- Eric Ries, Minimum Viable Product: a guide: Startup Lessons Learned, 3 August 2009. The original definition of MVP, taken up again in the book The Lean Startup (2011).
- CB Insights, The top 9 reasons startups fail: Analysis of 5 March 2026 on 431 funded companies that shut down since 2023: ran out of cash 70%, poor market fit 43%, timing or context 29%, unsustainable unit economics 19%.
- CB Insights, The Top 20 Reasons Startups Fail: Historical analysis of 101 post-mortems written by founders: no market need 42%, ran out of cash 29%.
- MIT NANDA, The GenAI Divide: State of AI in Business 2025: Preliminary results, July 2025: 95% of organizations see no measurable impact on the profit and loss account from their generative AI pilots. Sample of 52 organizations and 153 questionnaires.
- MAXYMIZE, How we work and what it costs: The ranges used in this note, with the ways of working together and what maintenance covers.
Written by Maximilian Giurastante
Founder and software developer, MAXYMIZE. Designs and builds SaaS platforms, custom business software and automations with language models. Over twenty years as a project leader in technology, audio and video systems integration.
Have a product idea and want to know what the first version costs?
Tell us about it in thirty minutes. We will tell you what we would put in the MVP, what we would leave out and what range it lands in.