An MVP (minimum viable product) is the simplest working version that is enough to test an idea with real users. The goal is not to release a perfect product but to answer one question: do people need this, and are they ready to spend time or money on it? If the answer is "yes", the product is scaled up; if it is "no", the direction is changed without losing several months and a large budget.
Key takeaways:
- An MVP is not a half-finished product: it is a small but working version that solves one core problem from start to finish.
- An MVP's job is to learn, not to sell: a hypothesis is tested with real users.
- An MVP is not always an app: it can also be a landing page, a video, a service delivered by hand, or a version assembled on a no-code platform.
- The first version includes only one core scenario; the remaining features are added as users ask for them.
- The success criterion is written down in advance: for example, "100 sign-ups in a month, and 30 of them come back a second time".
What is an MVP?
An MVP is a version of a product that can be built with the least effort, given to real users, and learned from through their behaviour. Eric Ries, who popularised the term, defines it like this: an MVP is the version of a new product that allows a team to collect the maximum amount of validated learning about customers with the least effort (Eric Ries).
Three words matter in the definition:
- Minimum. Only the features that solve the core problem. The "nice to have" list is left for later.
- Viable (working). The user can actually solve the problem. Ten features that half work are not an MVP; one fully working feature is.
- Product. People really use it. A presentation or a drawing does not count as an MVP.
A simple comparison: if the goal is to get a person from point A to point B, an MVP is not a car's wheel but a scooter. You cannot go anywhere on a wheel; a scooter, even though it is slow, solves the problem and shows that people really do want to get to point B.
What is a startup and how does it relate to an MVP?
A startup is a new business built on an idea that has not yet been proven and that aims to grow fast. It differs from an ordinary new business in its uncertainty: a person who opens a bakery knows there is demand for bread, whereas a startup does not yet know whether there is demand.
An MVP is precisely the tool for reducing this uncertainty. But it is not only startups that need one: when an existing company plans a new service, a mobile app or a customer account, the same question arises: will customers use it?
Why do you need an MVP?
An MVP reduces the main risk, that is, the risk of building a product nobody needs. CB Insights analysed 431 startups that have shut down since 2023: among the reasons for failure, running out of capital was cited in 70% of cases and poor product-market fit in 43%. The analysis describes running out of capital not as the root cause but usually as the final outcome (CB Insights). In plain words: money often runs out because the product has not found its customer.
An MVP gives you four things:
- Proof of demand. Saying "interesting" in a survey is easy; signing up and paying are real signs of interest.
- Budget savings. You find out which two of ten features are needed before you build them.
- Speed. You reach the market in weeks, not months, and start learning before your competitor.
- Evidence for investors and partners. Real user numbers are more convincing than the forecast in a presentation.
MVP, prototype and full product: what is the difference?
| Prototype | MVP | Full product | |
|---|---|---|---|
| What it is | A clickable mock-up with no system behind it | A small but genuinely working product | All the planned features |
| Goal | To show the idea, to test the design | To test demand with real users | To grow and earn |
| User | The team, a few test participants | The first real customers | The whole target audience |
| Duration | Days | Weeks or a few months | Months and years |
| Question | "Is this understandable?" | "Is this needed?" | "How do we scale this?" |
The sequence is usually this: prototype first, then MVP, then full product. We explain how a prototype is made in the article what is web design.
What types of MVP are there?
Writing code is not always required for an MVP. Nielsen Norman Group defines an MVP as the simplest version of a product or feature and lists its different formats, from a paper prototype to a version written in code (NN/g). Which type suits you is determined by the hypothesis you want to test:
| Type | How it works | What it tests |
|---|---|---|
| Landing page | One page describing the product and a "sign up" button | Are people interested in the offer? |
| Video or demo | A short video showing how the product will work | Is the idea understandable, and is anyone waiting for it? |
| Concierge | The service is delivered to the first customers by hand, without software | Do people pay for the result? |
| "Wizard of Oz" | The customer sees a finished system, while a person does the work behind the scenes | Is the process worth automating? |
| Single-feature product | An app or website with only one core feature | Do people use the core feature repeatedly? |
| No-code version | The product is assembled on ready-made platforms without writing code | Does the workflow work in real use? |
For example, to test a food delivery idea you do not need to write an app first: you can take orders through Instagram and WhatsApp and deliver them yourself. This is a concierge MVP. When orders multiply and become hard to manage by hand, the need for an app is considered proven. We compare the capabilities of no-code platforms in the article creating a mobile app.
How did famous companies start with an MVP?
- Dropbox. Founder Drew Houston made a three-minute video showing how the product would work. According to him, the beta waiting list grew from 5,000 to 75,000 people overnight (TechCrunch).
- Zappos. In 1999, founder Nick Swinmurn made shoe shops a simple offer: he would photograph their shoes and put them online, and when an order came in he would buy the shoes from the shop at full price (Fortune). With no warehouse and no stock, one question was tested: would people buy shoes online?
- Airbnb. According to the company's own history, it all began in 2007 when two hosts took in three guests at their home in San Francisco (Airbnb). There was no platform: just a simple website and a few air mattresses (Fortune).
- Buffer. Joel Gascoigne first built not the product but a two-page website, and watched whether people showed any interest at all. Then he added a pricing plans page between the two pages so that he could see who was ready to pay (Buffer).
What these stories have in common is this: none of them started with a full product. Each first tested a question the cheapest way, and built the product only after getting the answer.
How is an MVP built?
An MVP can be built in seven steps. The first four steps need no code and are the most important ones.
- Write the problem and the audience in one sentence. "Customers of small beauty salons in Baku have to phone to book, and the salons miss some of the calls."
- Write the hypothesis. "Salons are ready to pay 30 AZN (manat) a month for online booking." The MVP will test exactly this sentence.
- Choose the core scenario. The one path the user follows to solve the problem: finds a salon, picks a time, the booking is confirmed. Nothing else.
- Divide the features into four groups. Must have, nice to have, to revisit later, won't have. Only the first group goes into the MVP.
- Define the success criterion in advance. For example, "20 salons join in a month and 5 of them pay". Without a criterion, the result can be interpreted any way you like.
- Build it the simplest way. A landing page, a no-code platform or a single-feature app: whichever is enough to test the hypothesis.
- Measure and decide. Continue, change direction or stop. All three are normal outcomes.
What should and should not go into an MVP?
Take an online booking app for salons as an example:
| Goes into the first version | Left for later |
|---|---|
| Sign-up with a phone number | Social network login, profile photo |
| Choosing a service, a stylist and a free time slot | Stylist ratings and reviews |
| Booking confirmation and a reminder message | Bonus and loyalty system |
| A simple calendar for the salon | Reports, payroll calculation, warehouse |
| One language | Three languages |
| Payment at the salon | Online payment in the app |
Everything in the right-hand column is a useful feature, but none of it answers the core question, namely "will people use online booking?" Every extra feature delays the release and increases the budget; we show how this looks in numbers in the article mobile app development cost.
There are three things you do not economise on in an MVP: the core scenario must work without errors, user data must be protected, and measurement must be set up. An MVP without measurement is not a test, just a small product.
How much does an MVP cost and how long does it take?
The price and timeline of an MVP depend on its type: a landing page takes days and a small budget, while a single-feature app takes weeks or a few months. Published estimates show a wide range: in GoodFirms' 2026 survey, 78.2% of mobile app companies quoted up to $50,000 for MVPs and simple apps, while for software projects in general the small-project or MVP tier is described as a budget of under $30,000 and a timeline of 1–3 months (GoodFirms). These figures relate to the international market and do not directly reflect prices in Azerbaijan.
The factors that change the price the most:
- Platform. Web version only, one mobile platform only, or iOS and Android together.
- Roles. The customer only, or the customer, the provider and the administrator.
- Integrations. Online payment, map, SMS, CRM.
- Design. Ready-made components, or custom design.
If the hypothesis can be tested with a landing page or the concierge method, start there. An app should be built only after these cheap tests show demand.
What should you do after the MVP?
After release, the work continues by watching the numbers. Four metrics are enough:
| Metric | What it shows |
|---|---|
| Activation | How many of those who signed up performed the key action (for example, placed a first order)? |
| Retention | How many people used it again a week and a month later? |
| Payment | How many people paid or agreed to pay? |
| Recommendation | Do users recommend the product to others? |
The most important of these is retention: if people do not try it once and leave, the product is solving a real problem. Besides the numbers, talk to your first users: ten conversations teach more than a hundred survey questionnaires.
Depending on the result, there are three paths: if the metrics are good, the product is scaled up; if the problem is real but the solution does not fit, the direction is changed; if there is no demand, the project is stopped. The third outcome is also a success, because you learned it without spending a large budget.
What are the most common mistakes when building an MVP?
- The "one more feature" trap. The MVP grows every week and is never released.
- No success criterion. A criterion that is not written down in advance is later fitted to the result.
- Testing with friends. Friends and relatives praise you out of politeness. You need people who do not know you.
- A poor-quality core scenario. "Minimum" does not mean the core function can be buggy.
- Not setting up measurement. Without analytics, you cannot know what is happening.
- Not setting aside a budget for promotion. The first users do not come by themselves; advertising, social media and personal contacts bring them.
- Not accepting the result. Trying to rescue the situation by adding features when the numbers say "not needed".
How does Advertol approach app ideas?
At Advertol, the first step of an app project is a free strategy consultation: there the app's business goal and what goes into the first version are determined. The proposal is prepared individually once the list of features, the roles and the integrations are clear.
An MVP's fate is often decided not by the product itself but by where the first users will come from. Advertol is an agency based in Baku: website and mobile app development, Meta and Google advertising, SMM, CRM and AI automation are all run by one team, so the product and its promotion are built to a single plan. One of the published technology projects is the custom CRM built for Momento Travel; our way of working is described on the website and app development page.
Frequently asked questions
Are an MVP and a prototype the same thing?
No. A prototype is a clickable mock-up with no working system behind it; it is used to test design and clarity. An MVP genuinely works and is given to real users; it is used to test demand. Usually the prototype is built first, then the MVP.
Does an MVP mean a poor-quality product?
No. An MVP is short on features, not on quality. The core scenario must work without errors and comfortably; otherwise people will reject the poor execution, not the idea, and you will draw the wrong conclusion.
Does an MVP necessarily need a mobile app?
No. Often a landing page, a web version or a service delivered by hand is enough, and costs many times less. A mobile app is needed only when the idea itself depends on the phone's capabilities: camera, location, notifications.
Can you build an MVP without writing code?
In many cases, yes. No-code platforms make it possible to assemble a simple app or web service and are enough to test a hypothesis. The limitations show up when the product grows: speed, special features and platform lock-in. At that point the product is rebuilt in code.
Should I keep my MVP secret so that no one steals my idea?
Usually there is no need. The idea itself is rarely valuable; the value lies in execution and in what you learn about customers. A team that hides its idea cannot get feedback and increases the risk of building a product nobody wants.
What should I do if the MVP fails?
First separate out the cause: is there no problem, is the solution not right, or have people simply not heard about the product? In the first case change the idea, in the second the solution, in the third the promotion. Talking to users is the fastest way to tell these three causes apart.
Conclusion
An MVP is the cheapest way to test an idea in the market: one problem, one core scenario, a success criterion written in advance and real users. Before you start building an app, check whether the hypothesis can be tested with a landing page, a video or a service delivered by hand. Whatever the result, you will make the decision on numbers, not on guesswork.
If you want to discuss what should go into the first version of your app or platform idea, book a free strategy consultation or write to the Advertol team.
Sources
- Eric Ries — Minimum Viable Product: a guide, 3 August 2009
- Nielsen Norman Group — Minimum Viable Product (MVP): Definition, 27 March 2026
- CB Insights — The top 9 reasons startups fail, 5 March 2026
- TechCrunch — How DropBox Started As A Minimal Viable Product, 19 October 2011
- Fortune — Nick Swinmurn, Zappos, 5 September 2012
- Airbnb Newsroom — About us
- Fortune — Brian Chesky, Airbnb, 26 June 2015
- Buffer — Idea to Paying Customers in 7 Weeks: How We Did It, 16 February 2011
- GoodFirms — Software Development Cost Survey 2026, 28 September 2026