Most first conversations about an MVP start with a list: sign-up, profile, search, notifications, payments, an admin panel, an app for both sides. That list describes the product you want in two years — not the version you can test in the coming months.
This guide suggests a different order: first decide what you need to prove, then choose the deliverable that proves it, and only then break the idea into scope. At the end there is a worked example — marked as illustrative — of an idea broken into a now/later table.
What do you need to test?
Before talking about screens, write one sentence in three parts: who it is for, what problem it solves, and what the user will do differently if it works. That sentence is the hypothesis the MVP tests. If it is hard to write — that is the first sign the idea is still too broad for a first version.
| Part | Question | Sign the answer is still too broad |
|---|---|---|
| User | Who is the first person who will use this, and where do you meet them today? | "Small businesses", "everyone", both sides of a marketplace at once |
| Problem | What do they do today instead, and how much does it bother them? | The problem is described in terms of the solution ("they have no app") |
| Behaviour | What will they do differently after using it — an action you can observe? | "Will be satisfied", "will understand the value" — things you cannot measure |
A good hypothesis is one that can be disproved. "People want to save time" cannot be disproved; "shift managers in cafés will enter next week's schedule on their phone instead of in a WhatsApp group" — can.
Prototype, POC or MVP?
The three terms are often used interchangeably, but they answer different questions and cost differently. Choosing the wrong one is a common reason MVPs balloon: a working product gets built to answer a question a clickable prototype would have answered.
| Deliverable | Which question it answers | What it usually is | What it does not prove |
|---|---|---|---|
| Prototype | Does the user understand the offer and want it? | Clickable screens with no backend, sketches, or a landing page with a sign-up | That the product is technically feasible or that people will come back |
| POC (proof of concept) | Is the risky technical part possible at all? | Code that tests an integration, an algorithm or performance — no interface, no users | That anyone needs it |
| MVP | Do real users complete the core flow and get the outcome? | A working product, as narrow as possible, that users actually use | That the full product will succeed, or that it is ready to scale |
Sometimes the right order is two of the three: a prototype to test the offer, then an MVP around the flow users responded to. A POC enters only when there is a technical component without which the product does not exist — for example a dependency on an external system that may not allow what you need.
Breaking an idea into scope
The central tool is the core flow: the one path a single user takes from the problem to the outcome. Write it as a sequence of steps, then ask of each step — without it, does the user fail to reach the outcome? If yes, it is in the MVP. If not, it is a candidate for deferral.
Before: the idea as it arrives at the first meeting
- Sign-up and login for owners and employees, including Google and Apple login
- Weekly schedule builder with drag and drop, templates, recurrence and week duplication
- Shift swap requests between employees with manager approval
- Time clock, hours calculation and a payroll report
- Push, SMS and email notifications
- Internal team chat
- A multi-branch admin interface with reports
- iOS and Android apps plus a website
The core flow
- The manager enters the list of employees and next week's shifts.
- The manager publishes the schedule and employees receive a link.
- Each employee sees their shifts and confirms them.
- The manager sees who confirmed and who did not.
Four steps. Anything not required to complete them once with a real café — is deferred. The result is a now/later table in which every deferral has a reason.
After: the now / later table
| Component | Now / later | Reason |
|---|---|---|
| Entering employees and shifts | Now | Step 1 of the flow; without it there is no schedule |
| Publishing the schedule and a link for employees | Now | Step 2; this is exactly what replaces the WhatsApp group |
| Shift confirmation by an employee | Now | Step 3; this is the behaviour the hypothesis predicts — you must be able to see it |
| "Who confirmed" screen for the manager | Now | Step 4; without it the manager goes back to WhatsApp to check |
| Google and Apple login | Later | A personal link per employee is enough for the test; social login does not change the answer |
| Drag and drop, templates, week duplication | Later | Editing convenience; first check whether schedules get published through the app at all |
| Swap requests | Later | A second flow; it may turn out to matter more — then it becomes the next version |
| Time clock and payroll report | Later | A different product with accuracy and compliance requirements; unrelated to the hypothesis |
| Push, SMS and email notifications | Later (partly) | One channel — a message with a link — is enough to get the employee to the screen; the other channels later |
| Internal chat | Later | Competes with a tool the team already uses; not required for the flow |
| Multi-branch management and reports | Later | The first user is a single café; chains are a different audience |
| iOS, Android and a website | Now: one channel | Pick the channel where the first users actually are; the rest later |
Once this table exists, the next document almost writes itself: the users, the core scenario, the screens it needs and the acceptance criteria. This is where the decision becomes a document a development team — ours or another — can price and build from. App requirements document — a filled-in example and a template to download
What do you defer, and why?
There is no right number of features for an MVP, and no universal list of "things you always defer". There are four kinds of reasons that recur in most projects, and it is worth writing next to each deferral which one it belongs to:
- Not required for the flow — the user reaches the outcome without it (social login, editing convenience).
- A different flow — a second product or path that may become the next version (swap requests, payroll).
- A different audience — built for a user who is not the first user (chains, regional managers).
- Can be done manually — during the test a person can do it behind the scenes (sending the message, approving an exception).
Two things you do not defer even though they are not a "feature": a way to see what users actually do (basic events or at least a log), and a way to talk to them after use. Without these the MVP produces an impression, not an answer.
The reverse is also true: some things look like "infrastructure" and are still deferred — for example the ability to scale far. An MVP that works for a hundred users and needs changes to work for ten thousand is a good outcome, not a failure; what matters is knowing in advance where the limit is and writing it down.
Hypothesis, metric and stop condition
Before development starts, write three lines you will read again after launch. The hypothesis already exists; add a metric and a stop condition. The metric is the behaviour from the hypothesis translated into something you can count. The stop condition is the pre-agreed answer to "when will we admit this does not work the way we thought".
| Line | In the example (illustrative) | What matters in the wording |
|---|---|---|
| Hypothesis | Shift managers in small cafés will publish the weekly schedule through the app, and employees will confirm inside it | User, problem and behaviour — not a description of the features |
| Metric | Of the cafés in the test: how many published a schedule in the second consecutive week, and what share of shifts were confirmed inside the app | A count of the predicted behaviour, in a defined group, within a defined window; not "sign-ups" and not "downloads" |
| Stop condition | If after the test window most cafés went back to WhatsApp — stop and find out why before adding features | Agreed in advance, written down and tied to the metric — not "let's see how it goes" |
When do you move to the next version?
The decision to continue rests on three sources, not on any one of them alone:
- Feedback — what users said after use, and especially what they did when something was missing (worked around it? gave up? asked for it?).
- Usage — the metric defined in advance, alongside what you did not expect: where they got stuck, what they never touched, what they used differently than intended.
- A business decision — whether the direction still fits what the business wants to build, and what budget and time exist for the next step.
The next version does not have to be "more features from the original list". Often it is one of three other things: deepening the existing flow (making it faster and clearer), widening the audience (a second user type), or pulling a component from the "later" column that turned out to be critical — for example the swap requests from the example, if most employee questions were about exactly that.
And if the stop condition was met — that is not an empty result. A narrow MVP that showed the hypothesis was wrong saved the cost of building the full product on that same hypothesis. In that case you go back to the hypothesis line, not to the feature list.
What this looks like when working with us
When a startup comes to us with a list, our first step is not a quote but the table from this guide: the hypothesis, the core flow, and a now/later column with reasons. Only after that is there a scope that can be priced and committed to. How our MVP team works, what is included and the orders of magnitude — on the service page. A development team for startups — from MVP to the next round
And if the next question is what it costs — what the price of a first version is made of, and what moves it up or down — we published a separate guide on that. How much app development costs in Israel in 2026 — the cost breakdown