What is an MVP? Testing your app idea without spending a big budget

The short answer to what is an MVP: the smallest possible product that gives users real value and tests your riskiest assumption. MVP stands for minimum viable product, and the key word is "viable". An MVP is not a half-finished app; it's a small app that works from start to finish.

It helps to separate an MVP from two things it often gets confused with. A prototype is a set of clickable screens that doesn't run on real data; it's good for explaining the idea, but it doesn't measure how users behave. A full version includes every feature you have in mind and takes months. An MVP sits between the two: real users do a real task, and you measure what happens.

The hardest part of planning an MVP is finding the one flow at the heart of the product. I ask clients to finish a single sentence: "When a user opens this app, they should be able to ...". If more than one thing goes in the blank, the choice hasn't been made yet.

In a field team app, for example, the core flow might be "the person in the field logs the job with a photo, and the office sees it right away". Reports, bonus calculations and calendar integration only make sense once that flow works. The standout feature of Wingardium, an agriculture app I developed, is real-time tracking; in a product like that, the first question is also how the user can see the information they track by the shortest route.

• Write down how the user does this job today: Excel, a WhatsApp group, a paper notebook, whatever they use.
• Find the step in that current way of working that wastes the most time or causes the most mistakes.
• Give the MVP a single job: make that step noticeably easier.
• Work out the fewest screens the flow needs; 5 to 10 is usually enough.

What sets an MVP's budget is less what you put in and more what you leave out. In a first version we usually postpone:

• A detailed admin panel: at first, a database interface or a simple table screen is often enough.
• Several sign-in methods: if email sign-in does the job, leave Google, Apple and phone sign-in for later.
• In-app payments: taking payment from the first users by bank transfer or a payment link lets you build the payment integration once demand is proven.
• Features users won't notice in the first week, such as multiple languages, dark mode or detailed notification settings.
• Automated reports: in the first months, exporting the data by hand and looking at it is cheaper.

Leaving things out doesn't mean cutting corners on security. Sign-in, data permissions, the privacy policy and store rules have to be complete in an MVP too. The App Store and Google Play don't go easier on you because it's a first version.

An MVP you don't measure is just a small app. Before launch, I suggest writing down which result would confirm the idea and which would disprove it. Download count alone isn't a good measure; people download out of curiosity and never open the app again.

• Activation: how many of the people who downloaded the app completed the core flow at least once?
• Retention: how many of the first week's users still open it in the following weeks?
• Time to complete: how much faster is the core task compared with the old way?
• Qualitative feedback: the complaints and requests that come up most in short conversations with the first users.
• Willingness to pay: if you're planning a paid model, how many people agree to pay?

You don't need a heavy analytics setup for this. Logging a few basic events (sign-up, flow started, flow finished) and looking at them weekly is enough at first. If you add an analytics tool, remember to include it in the store data declarations too.

An MVP for iOS and Android built with React Native, with 5 to 10 screens and a simple backend, starts at around 150.000 – 350.000 TL, excluding VAT (KDV). As you add accounts, payments, notifications and an admin panel, the project turns into a mid-size app and the range moves up to 350.000 – 900.000 TL. That gap alone explains why you should keep the scope narrow.

Time also depends on scope. An MVP with a clear core flow and a simple design can be ready to test in anywhere from a few weeks to three months. Adding a few weeks for store review and fixes from the first users is realistic. What stretches the timeline is usually not the code, but new feature requests added along the way.

The process is the same for a business in Adana and for a founder in another city or country; I work remotely and show you a working build every week. That way you see where the scope is heading every week, not at the end of the project.

1. 01

   Write down the assumption

   Make the sentence "These people have this problem and would use this solution" concrete. Who, which problem, which solution.

2. 02

   Choose the core flow and the metric

   One flow, two or three numbers to measure it, and a threshold for success.

3. 03

   Prototype the screens

   Show the flow to a few potential users before writing code. This is where fixes are cheapest.

4. 04

   Build and test on real devices

   Work in weekly demos, and distribute the test build through TestFlight and a Google Play testing track.

5. 05

   Launch and bring in the first users

   Know who will use it before launch. Bringing the first users in from people who already know you, rather than from ads, speeds up feedback.

6. 06

   Measure and decide

   Based on the results, decide to continue, change course or stop. Stopping is also a successful MVP outcome: you didn't spend a big budget on the wrong idea.

• Putting everything in the first version: with "they won't use it without this too", the scope grows and the MVP turns into a full version.
• Not setting a metric: after launch, nobody can decide whether the numbers are good or bad.
• Postponing design: simple doesn't mean careless. On a confusing screen, users test the interface, not the idea.
• Skipping the technical foundation: messy code written to ship fast has to be rewritten when the MVP succeeds. A shared React Native codebase and a clean backend structure lower that risk.
• Leaving the store process to the last week: if account verification, the privacy policy and the review timeline aren't planned from the start, the launch slips.