Start with a sentence
Before any feature list, finish this sentence: “[One type of user] can [do one job] without [the pain they have today].”
“A single-outlet restaurant owner can take orders from regulars without copying WhatsApp messages into a notebook.” “A recruiter can track candidates for each role without a shared Excel file.”
If the sentence needs “and” several times, the first version is too big. The rest of this guide turns that sentence into a scope.
Prototype, MVP or pilot?
These words get mixed up, and the confusion causes arguments about scope.
A prototype is clickable screens that show an idea. Nothing is saved. It tests whether people understand the concept.
An MVP is working software that real users use for a real task. It is small, but it must work reliably for that task.
A pilot is a trial of a finished or near-finished product with a limited group, often one branch or one client.
Agree which one you’re building first. Expecting a prototype while paying for an MVP, or the reverse, disappoints both sides.
Step 1: Pick one primary user
Choose the person whose problem the product must solve first. Other users (managers, accountants, your own admin team) will matter later. In the first version they get the minimum, and often a manual workaround.
Step 2: Decide what success looks like
Pick a sign you can observe once people use it:
- outlets keep taking orders through the app after the first month;
- recruiters add new candidates in the app instead of the spreadsheet;
- customers pay the link without a follow-up call.
If you can’t say what success looks like, you can’t decide what to leave out, because everything seems equally important.
Step 3: Write the core flow
Describe the job as the user does it. For the restaurant:
- The customer opens the link from WhatsApp.
- They pick items and a delivery slot.
- They pay through Razorpay or choose cash on delivery.
- The outlet accepts the order.
- The customer gets a confirmation.
Everything in the MVP should serve a step here. Loyalty points, reviews, a multi-outlet dashboard and referrals might all be good ideas later. None appears in this flow.
Step 4: Do the back office by hand
Users see the flow. They don’t see how accounts get created, how reports get made or how refunds get processed. In a first version, much of that can be manual:
- you create accounts yourself instead of building self-signup with verification;
- reports come from a database export into a spreadsheet;
- refunds go through the payment gateway’s own dashboard;
- at low volumes, invoices come from the accounting software you already use.
Each manual step is a feature you don’t build until you know it’s worth it. When the manual work starts eating hours, automate it.
Step 5: Keep the essentials
Cutting too far fails too. Almost every first version needs:
- secure login and password reset, because locked-out users rarely return;
- a split between admin and users, so customers can’t see each other’s data;
- backups, because real users means data you can’t lose;
- correct GST calculation and invoice details, if you charge;
- a visible way to get help, such as a support email or WhatsApp number;
- a clear note on what personal data you collect and why, and no more data than the flow needs.
Step 6: Limit platforms and integrations
Each platform and integration multiplies the work.
A responsive web app (how we build them) runs on phones and desktops from one codebase. Native apps make sense when the job needs something browsers do poorly, such as heavy offline use or deep device access.
Launch in one language unless your first users need a second (why that decision matters early).
Add integrations only where the flow needs them: a payment gateway if people pay, WhatsApp if that’s how users are reached. A sync with Tally or Zoho can often wait, with a CSV export in the meantime.
Step 7: Write it down
Turn all of this into a document a team can quote against: the user, the flow, the screens, the integrations, what is out and what stays manual. Our guide to scopes of work lists what that document should contain. Then run your feature wish list through the four-question test.
A final check: could a real user complete the core job with only what is listed? If yes, you have an MVP scope. If they’d get stuck, something essential is missing.
The usual ways MVP scopes go wrong
Teams build for every future user type at once, or build admin dashboards before there’s anything to administer. Each stakeholder gets “just one small” integration. Every screen gets polished before anyone has used it. Or, at the other extreme, login and data basics are skipped to save time, and early users leave.
The first thing we ask is which job the first version has to do. Once that job is named, every item on the list gets a plain answer: the job needs it, or it waits.