Scoping an App MVP Without Cutting the Wrong Corners

Most failed MVPs are not too small. They are a complete product with every feature reduced to eighty percent, which produces something that does everything badly and answers nothing. A useful MVP does one thing at full quality and openly omits the rest.

Name the one question to answer

Before scoping anything, write down the single riskiest assumption in the business. Will restaurants actually update their menus? Will drivers accept jobs through an app instead of a phone call? Will parents pay for this monthly? The MVP exists to answer that question with real users and real money, and every feature either serves it or waits.

Write the answer as a number you would accept. "Thirty of the first fifty restaurants update their menu at least twice in the first month." A target you wrote before launching is the difference between learning something and rationalising whatever happens.

Cut scope by user, not by quality

The right way to make an MVP smaller is to serve fewer people, fewer cases and fewer platforms, at full quality. The wrong way is to serve everyone with everything half-built.

• One user type first. Build for the restaurant owner, not the owner and the customer and the rider.
• One platform first, chosen by where your users are. In Nepal that is Android by a wide margin, and shipping iOS later is cheaper than shipping both badly.
• One city, one sector, one workflow. Geographic and vertical narrowing costs you nothing you need yet.
• Manual behind the scenes. If a human can do the matching, the moderation or the dispatch for the first hundred orders, do that instead of building it. You will learn the rules you would otherwise have guessed at.
• Cut the admin panel. A spreadsheet and database access will carry you further than teams expect.

Keep quality where the user actually feels it

Some things cannot be a prototype even in version one, because failing at them destroys the trust you need to learn anything. Sign-up and login must work every time. Anything touching money must be correct and reconcilable. The core action must be fast on a cheap phone. Data must not be lost when the connection drops, which for Nepali users is a weekly event rather than an edge case. Crash reporting must be in from day one, or you will be guessing about why people left.

Plan to throw some away

Some of what you build is scaffolding, and it is cheaper to admit that in advance. Say out loud which parts are deliberately temporary, so nobody defends them later out of sunk cost, and so nobody builds a second feature on top of a foundation that was always going to be replaced. A hard-coded pricing table, a manual approval step, an admin flow that is really a database query: fine, labelled, and scheduled for replacement.

What should not be temporary is the data model. Migrating a schema after launch with real users on it is the expensive kind of rework, and it is worth an extra week of thought before the first line of code.

Launching on the stores

The store listing is part of the product, not an afterthought on launch day, and it is where a surprising share of installs are won or lost. Most people decide from the first screenshot and the first line of the description, before reading anything.

• The title carries the most weight. Put the actual function in it, not only the brand name, so a search for what you do can find you.
• Screenshots are read as an advertisement, so caption them. The first two carry almost all of the decision.
• Write the first line of the description for a person deciding in two seconds, and the rest for the store's search index.
• Reviews and rating drive both ranking and installs. Ask for a review after a moment of success in the app, never on launch, and reply to negative ones.
• Publish an update on a regular cadence. Both stores favour apps that are maintained, and an app untouched for a year sinks quietly.
• Get the privacy declarations right the first time. A rejection over data disclosures costs a week you did not budget.

Budget for review time, and budget for a rejection. Assume at least a few days for a first submission on iOS, and have the reviewer's test account, demo data and a written walkthrough ready before you submit rather than after they ask.

The question is not what can we cut. It is what is the smallest thing that would teach us whether this works.

What the first release should include

In practice this comes down to a short list: the single core workflow, working properly on the platform your users hold; authentication; whatever payment or transaction the business depends on; crash and error reporting; basic product analytics on the three or four events that tell you whether the core action happened; and a way for users to contact a human. Everything else is version two, and version two is much easier to plan once real people have used version one.

What a first version costs and how long it takes

For a single-platform app with one core workflow, authentication and a payment or transaction step, plan on six to twelve weeks and a starting figure around Rs 320,000 for Nepali clients or about $4,200 internationally. That is a starting point against a written scope rather than a quote, and the things that move it are predictable: the number of distinct user types, whether payments are involved, how many external systems you have to integrate with, and whether anything has to work offline.

The estimate people get wrong is not the build. It is the month around launch: store submission and the rejection you did not plan for, the content and legal text nobody wrote, the test accounts, the support channel, and the first round of fixes from real users on devices you did not own. Budget a third of the build time again for that period and the launch stops being a crisis.

Deciding what happens after launch

Set the review date before you launch, because after launch there is always a reason to wait one more week. Six to eight weeks of real usage is normally enough to answer the question you wrote down at the start, provided you instrumented the three or four events that matter and provided you are willing to accept the answer.

• It worked: widen the scope deliberately, replacing the scaffolding you labelled as temporary before adding anything new.
• It half worked: find out which half. Usually one user type is engaged and another is not, and the honest response is to narrow further rather than to add features.
• It did not work: stop. The money already spent is gone either way, and continuing because it would be embarrassing to stop is the most expensive decision available.
• You cannot tell: that is an instrumentation failure, and it is the one outcome that is entirely preventable. Fix the measurement before building anything else.

The stack choice underneath this is covered in React Native vs Flutter, and how we run app builds is on our mobile app development page.