Minimum Viable Product (MVP)

MVP meaning: what "minimum" and "viable" each require

The two words in minimum viable product pull against each other, and that tension is the point.

• Minimum: build only what is needed to test your main assumption. Anything that does not help answer that question waits.
• Viable: it must actually work and solve the problem well enough that real people will use it. A broken or confusing product teaches you nothing, because users leave before you learn anything.

An MVP is not a cheaper version of the full product. It is the smallest product that can answer the most important question about your business.

A worked MVP example

Suppose you want to build a booking app for beauty salons in Erbil and Sulaymaniyah. The full vision includes online payments, loyalty points, staff scheduling, reviews, a salon dashboard, marketing tools and three languages.

The riskiest assumption is simple: will customers book through an app instead of calling or messaging the salon? The MVP tests exactly that:

• Customers can browse a handful of partner salons, see available times and book.
• Salons get a notification and confirm the booking.
• The app launches in the language most early users read, with right-to-left layout if it is Kurdish or Arabic.

Payments, loyalty, reviews and marketing tools wait. If bookings happen and customers come back, you have evidence to invest further. If they do not, you found out for a fraction of the full budget.

MVP vs prototype vs proof of concept

• Proof of concept: answers "can this be built?" It is usually internal, partly working and often thrown away. The outcome is a technical go or no-go.
• Prototype: answers "how would it look and work?" It is often a clickable mockup shown to stakeholders and test users. The outcome is design feedback.
• MVP: answers "will people use it?" It is a real, working product in the hands of real customers. The outcome is usage data and revenue signals.

Common MVP mistakes

• Too many features. Adding "just one more" until the MVP becomes a full product that took twice as long.
• Too little quality. Skipping basic reliability, security or usability, so users leave for reasons unrelated to the idea.
• No way to measure. Launching without tracking or clear success criteria, so nobody knows whether it worked.
• Treating it as throwaway. Some MVP code will be rewritten, but the data model and core architecture should be sound enough to build on.

How to scope your MVP

1. Write down the single assumption that would sink the business if it were wrong.
2. List every feature you have in mind, then mark only the ones needed to test that assumption.
3. Decide what success looks like before launch: a number of bookings, active users or paying customers.
4. Choose the platform that reaches your first users fastest. For many mobile MVPs, a cross-platform framework covers iOS and Android from one codebase.
5. Sketch the next two or three releases based on what you might learn.

If you are scoping an MVP for a mobile app, our mobile app development team can help you decide what belongs in version one.