What Is an MVP? How to Decide What to Leave Out of the First Version

MVP is one of the most used and most misunderstood terms in the software world. It does not mean a cheap product, nor a half-finished one. It means the smallest setup built to answer one question. This article explains how to choose that question and how to decide what to leave out of the first version.

What is an MVP, and what does it stand for? MVP is the abbreviation of minimum viable product; on Turkish sites you will see it as minimum uygulanabilir ürün (asgari uygulanabilir ürün). It is the smallest working version of a product idea that is enough to test its most critical assumption with real users. The aim is not to release an incomplete product, but to get a data-based answer to the question “will people actually use this?” at the lowest possible development cost.

What an MVP is, and what it is not

An MVP (minimum viable product) is the smallest version of your product that is enough to test one assumption. The critical word here is “viable”: it genuinely does the job it does; it just does little.

• Not an MVP: A product that is half-finished, works with errors or has weak security. The user feels it is “incomplete” and never comes back; worse, it gives you no result either, because you cannot tell whether it was the product or the idea that failed.
• An MVP: A product that does one job properly, from start to finish. The user says “if only it also had this” — that is the reaction you want.

Write this down first: which assumption are you testing?

An MVP is an experiment, and every experiment has a hypothesis. Before narrowing the scope, complete this sentence: “I believe people will …; I will know by looking at the number of ….”

Examples:

• “I believe small shop owners will track their stock from their phone; I will know by seeing at least 8 of the 20 businesses that sign up log in three times a week for two weeks.”
• “I believe customers will book appointments through the app instead of by phone; I will know by seeing at least a quarter of appointments come through the app by the end of a month.”

If you cannot write this sentence, you also do not know what you will judge the MVP by. “People liked it” is not a result; did they use it, did they come back, did they pay — the criterion must be one of these.

A method for narrowing the scope

Three questions let you shorten the list:

• One user type: If there is more than one side (buyer–seller, customer–business), decide whose problem the first version solves. You can temporarily do the other side’s job by hand yourself.
• One flow: The single operation that is the backbone of the app. If it is “placing an order”, the first version has no campaigns, no favourites and no recommendation engine.
• One outcome: What does the user have in hand after using this product? Anything that does not produce that outcome is outside the first version.

Look at the feature list and ask, “if we remove this, does the product stop being useful?” If the answer is “it still works”, remove it.

Three things you never cut in an MVP

Scope gets cut; quality does not. These three must be complete even in the first version:

• The main flow working properly: Do little, but do it without errors.
• Data security: If you are collecting user data, this is not the place to say “let’s keep it simple for now”.
• An admin screen: An interface where the business side can see what is going on and intervene. When this is forgotten, the product goes live but cannot be managed.

Ways to test without writing code

Some assumptions can be tested without building software, and this is the cheapest route:

• A one-page landing page: A page describing the product and a sign-up form. How many people leave their details? This is the first signal of demand.
• Running it by hand behind the scenes: Do the work that looks automatic to the user manually in the background. Matching appointments, preparing recommendations, forwarding orders can all be done by hand at first. This is also how you learn which rules are needed.
• Building with ready-made tools: Set up the flow with form, spreadsheet and messaging tools and try it with a few real users.
• A clickable design: With an interface that does not work but can be navigated, tell the user “do this” and watch where they get stuck.

The knowledge gained from these methods directly defines the scope when you start development.

How do you read the result?

An MVP gives one of three results, and all three are valuable:

• It worked: Usage met the criterion you set. You now choose the next features not by guessing, but by looking at where users get stuck.
• It partly worked: A different audience used it than the one you expected, or a feature you did not expect stood out. This is usually the most instructive result; you have grounds to change direction.
• It did not work: Painful, but cheap. Had you built the same idea at full scope, you would have learned the same lesson at a far higher price.

Being able to accept the third result from the start is the real benefit of the MVP approach.

Common mistakes

• Going live without setting a criterion: Interpreting the result turns into an argument.
• Developing without finding users: You should plan who will try the MVP before development is finished. Product ready, no users — this is a common situation.
• The “let’s add this too” loop: If the scope started growing before launch, it has stopped being an MVP.
• Giving up too early: Low usage in the first week is usually a problem with the announcement, not the product.
• Making temporary solutions permanent: If the steps you ran by hand worked, they should be automated before scale grows.

Frequently asked questions

How long does an MVP take?

It depends on how narrow the scope is and whether the content is ready; giving a timeline upfront would not be right. What really shortens the time is shortening the feature list. Once the scope is clear, we give the schedule in writing.

Can I extend the MVP later, or does it get rewritten from scratch?

This is a matter of technical choice and should be discussed from the start. An MVP built with a “let’s launch fast and throw it away later” approach may have to be rewritten when it works. If it is to be built ready to grow, the initial cost rises a little — we decide together at the start of the project which you prefer.

Is an MVP enough for an investor?

Investors generally look for evidence, not ideas: people using it, repeat use, payment. An MVP is the way to produce that evidence, but what produces the evidence is not the MVP itself — it is the usage data it collects.

My competitor is full-featured; how do I compete with an incomplete product?

You don’t compete — you solve one problem for a narrow group better than they do. The target of an MVP is not the whole market, but the first group of users.

Does MVP mean cheap?

It means cheaper, not cheap. The scope shrinks, but the quality of the work does not; servers, security and testing are still required.

Let’s build the first version of your idea together

Share your idea, who will use it and the result you need to see before you can say “it worked”; let’s decide together what stays in the first version and what waits. You can look at our mobile app development and custom software development services and get in touch — we work in English or Turkish. For the budget side, see our mobile app cost article.