MVP or full app: what to build first

What an MVP is, and what it is not

MVP stands for minimum viable product. It is the first release of your product that real people can use to do the main thing it promises, built properly and running on real infrastructure. It is small, but it works.

An MVP is not a clickable mock-up, a slide deck or a prototype that only runs on a developer's laptop. Those are useful for discussing ideas, but you cannot put them in front of customers and learn from how they use them. It is also not a low-quality version of the full app. The scope is minimal; the quality is not.

A good MVP also has the foundations the next releases will need: proper accounts and permissions, a clear structure for the data, backups, and code another developer can read. Cutting features is fine. Cutting those foundations means rebuilding later, usually at the moment the product starts to work.

Choosing the must-haves

Start from the one job your product must do well for one type of user. For a clinic app it might be booking an appointment; for a marketplace, a buyer finding and contacting a seller; for an internal tool, replacing the spreadsheet everyone fights over. Then go through your feature list and ask of each item: can a user do that main job without it?

Must have: without it, the main job cannot be done.
Should have: it makes the job easier, but there is a manual way around it for now.
Later: useful, but it depends on knowing how people use the product first.

Be strict. Admin dashboards, detailed reports, multiple user roles, notifications for every event and a second language for the interface are often useful, and often not needed in week one. Many can be handled by hand behind the scenes in the first release.

Every feature you add to the first release delays the day you learn whether the first one was right.

A short discovery sprint to fix the scope

If the idea is new, the scope is a set of assumptions: which feature matters most, how users will move through the product, which integrations are needed. A short discovery sprint, typically two to three weeks with a fixed scope, turns those assumptions into decisions. It covers who the product is for, the core flow screen by screen, the technical choices, and it ends with a working first version and a written plan for what comes next.

The point is to answer the expensive questions at the start, when changing your mind costs days, not at the end, when it costs months.

When a full app from day one makes sense

An MVP is not always the right answer. Building the complete product from the start can make sense when:

You are replacing an existing system, and users already depend on all of its functions.
The scope is already clear and documented, for example a client portal with known screens and rules.
Regulation or contracts require certain features from launch, such as access rights, audit trails or specific security measures.
The product only works if several sides are present at once, and a partial version would not be usable by any of them.

Even then, the build should be split into stages with dates and approvals, so you see working software regularly instead of waiting for one big delivery.

Web or mobile first

A web app runs in the browser on any device, can be updated at any moment, and is reached through a link. It suits products used at a desk, internal tools, admin areas, and most first releases. A mobile app installed from the App Store or Google Play suits products used daily on the move, or that need the camera, location, offline use or push notifications. It also adds store reviews to each release.

A common path is to start on the web, built to work well on a phone, and add mobile apps once usage shows they are worth it. Cross-platform frameworks now let one codebase serve iOS and Android, which makes adding mobile later more practical. If your users clearly live on their phones from day one, start there.

Planning the second release from real usage

The second release should be planned from what happens after the first one goes live, not from the original wish list. Before launch, decide what you will measure: sign-ups, how many people complete the main job, where they stop, what they ask for in support messages. Talk to early users. Then revisit the "should have" and "later" lists with that evidence, and choose the next release.

Some features from the original list will turn out to be essential. Others will quietly disappear, because nobody asks for them. Both outcomes are useful; they are how a product gets better without wasting effort.

Questions to settle before you start

Who is the first user, and what is the one job the product must do for them?
What will exist at the end of the first release, written down screen by screen?
What will you measure after launch, and how?
Who owns the code, the accounts and the data?
How will the second release be scoped and quoted?

How we work at Qafza

We build SaaS apps and custom software, often starting with a Discovery Sprint of two to three weeks that ends with a working first version and a plan, with the sprint fee credited if you continue to the full build. Full builds, on web and cross-platform mobile, are delivered in stages with dates and approvals, and on full payment the code and accounts are yours. We promise the scope, the dates and the quality; once real users arrive, we measure sign-ups and usage with you.

A working MVP in 2–3 weeks, not slides.Book a 30-minute scope call