What is an MVP? Launching the first version of your app faster and cheaper

MVP vs prototype vs full product

MVP stands for minimum viable product. Many people confuse it with a prototype, or treat it as a shrunken copy of the final product with every feature. The table below shows the difference between the three stages, because each one answers a different question and needs a different budget and timeline.

A practical example

A salon booking app: the MVP is a customer picking a service and slot and getting a reminder, and the salon seeing bookings. Loyalty points, deposits, reviews and multiple branches come in version two, after you see people actually booking.

How to pick MVP features

• Write the core user journey step by step
• Remove every feature that doesn’t block that journey
• Use temporary manual work behind the scenes where possible
• Pick one success metric (e.g. weekly bookings)

How to scope an MVP in practice, step by step

Scoping is the hardest part of an MVP, because every feature feels important while the idea is still in your head. The steps below turn the idea into a clear task list that can be built in weeks rather than months. Once the list is specific, estimating how much an app costs in Iraq for your first version becomes far more accurate than estimating a vague idea.

• Describe the problem in one sentence and exactly who has it, e.g. “Salon owners lose appointments because booking happens only by phone.”
• Pick a narrow first segment: one city or one type of customer instead of “all of Iraq.”
• Map the core user journey from the first screen until the user gets value, e.g. sign up → choose a service → pick a slot → confirm.
• Sort every proposed feature into: essential to the journey, useful later, or just nice to have. Keep only the essentials.
• Decide what will be done manually for now: confirming orders by phone or WhatsApp, entering data from a simple panel, reporting from a spreadsheet.
• Choose the first platform based on your audience: Android, iOS or both via Flutter, or a web app if that is enough to test the idea.
• Write a success criterion and a decision date: what must happen in the first weeks after launch for the idea to count as proven?
• Freeze the scope until launch, and log every new idea in a version-two list instead of adding it now.

Iraq-specific considerations

An MVP that works in another market can stumble in Iraq if it ignores how people pay, communicate and get online. These points shape the scope from day one; ignoring them means your test results measure usage friction rather than the value of the idea:

• Cash on delivery first: many customers prefer it, so start with it and add e-wallets once demand is proven. Review the options for online payments in Iraq and ZainCash integration before deciding what to integrate in version one.
• Dinar and dollar: decide from the start which currency you price in and which you display, and show the price clearly in dinars if your customer pays in dinars, so you don’t have to rework the database and invoices later.
• WhatsApp is a ready-made channel: instead of building in-app chat, a button that opens WhatsApp for support or order confirmation is often enough, with your team sending messages manually at first.
• Arabic first: design the interface right-to-left from day one, write copy in language your customer understands, and postpone English or Kurdish if your first segment doesn’t need them.
• Patchy connectivity and power cuts: keep the app light, save what the user typed if the connection drops, retry automatically, and show a clear message instead of a blank screen.
• Addresses: if your product involves delivery, use a text description, a map pin and a phone number instead of a formal address form that doesn’t match how addresses are described locally.

What an MVP is not

An MVP isn’t a shoddy, buggy app. It’s a small scope built to high quality. A bad experience teaches you nothing about your idea — only about poor execution.

What to measure after launching an MVP

Launch is the start of learning, not the end. Before launch, pick a few simple metrics and review them weekly — and don’t settle for download or follower counts, which don’t tell you whether the product is actually useful:

• Activation: how many sign-ups completed the core journey at least once?
• Retention: how many used the product a second and third time without a reminder from you?
• Willingness to pay: do customers actually pay, or order the service at its real price?
• Drop-off point: the screen where most users leave reveals the first thing to fix.
• Messages and feedback: repeated WhatsApp questions and calls are a rich source of what the product is missing.

When to move to version two

Move to version two when users come back to the core journey regularly, the same requests repeat across several customers, and the manual workarounds behind the scenes become a burden on your team. At that point you know exactly what to build next, because the version-two list is based on real usage, not guesswork.

If people don’t use the first version, adding features won’t save it. Go back to interviews, adjust the idea, the target segment or how you reach it, then test again. That isn’t failure — it’s exactly what an MVP is designed to reveal at the lowest cost.

Common MVP mistakes

• Building everything “because the competitor has it”: the competitor has years of development behind them; you need to prove your idea first.
• Starting development before talking to real customers from the target segment.
• Building a complex admin panel before there is anything to manage.
• Neglecting quality because it’s “only version one,” so bugs spoil the test result.
• Choosing a technology or architecture you can’t build on, forcing a full rewrite after success.
• Not defining a success criterion, so the post-launch decision comes down to personal impressions.
• Delaying launch again and again to add “one last feature.”
• Opening store accounts in the developer’s name instead of your company’s; read how to publish an app to the App Store and Google Play from Iraq before launch.

Start your first version with a clear scope

If you have an idea and want to turn it into a launchable first version, the first step is defining the core journey and what can wait. The Al-Arjan team can help you scope it and then handle mobile app development in Iraq with an architecture you can build on in version two. If your idea is a web platform or a system to run an existing business, see custom software. Describe your idea and request a quote for your first version.