An MVP includes one core user scenario carried through to the end: the path from entry to the target action, basic authentication, an admin panel, and analytics. Everything else — extra roles, a second platform, integrations "for later growth", and fine-grained settings — moves to the following versions. The test is simple: if a feature can be removed and the hypothesis can still be verified, that feature does not belong in the MVP.
Contents
An MVP is not a "cut-down product" — it's a testing instrument
The central misunderstanding around MVPs: they get treated as "the product we couldn't afford in full". In reality an MVP answers one question — will people use this and pay for it. Anything that doesn't help obtain that answer is removed from the first version: not because it's "expensive", but because it lengthens the road to the answer.
An MVP answers one question — will people use this and pay for it.
The practical consequence: MVP scope is defined by the hypothesis, not the budget. First you phrase what exactly is being tested — "restaurants will take bookings through the app", "sales teams will run their deals in our system" — and only then decide what minimal product verifies it.
What always belongs in an MVP
- 01Core scenarioone user path to the target action
- 02A way inlogin exactly as complex as the scenario demands
- 03Admin panelcontent, enquiries and users — from day one
- 04Analytics and eventsthe metrics are the MVP's deliverable
The standard composition of a first version looks like this:
- The core scenario end to end: one user path to the target action — an order, a booking, an enquiry, a subscription.
- A way in: registration and login exactly as complex as the scenario demands (an SMS code or social sign-in is often enough).
- An admin panel: content, enquiries, and users need managing from day one, otherwise every tweak becomes a developer task.
- Analytics and events: without them there is nothing to discuss a month later — the metrics are the MVP's deliverable.
- Payments — if the hypothesis is about money: willingness to pay is only verified by a real payment, not a "Leave a request" button.
- One platform: web, PWA, or a single native app — whichever one your early audience lives on.
What can almost always wait for V2
The list below is not "useless features". These are features that don't help verify the hypothesis — which means their place is in the post-launch roadmap:
A developed system of roles and permissions
- Why it can wait
- "User" and "admin" usually suffice in a first version.
Second and third platforms
- Why it can wait
- If you launched on the web, iOS and Android can wait for demand to be confirmed.
Integrations "for growth"
- Why it can wait
- Exchange with 1C, inventory, and accounting connects once there is something to exchange.
Personalization, recommendations, gamification
- Why it can wait
- They work on retention, and retention matters after there is a stream of users.
Fine profile settings, themes, multiple languages
- Why it can wait
- These almost never affect hypothesis testing.
In-product support chat
- Why it can wait
- At the MVP stage WhatsApp covers it perfectly.
The numbers: InterLAB's MVP sprint
6–126–12
weeks from brief to release
2–52–5
million ₸ — budget reference
50%50%
paid at the start, 50% at release
At InterLAB the first version of a product is built as an MVP sprint: 6–12 weeks from brief to release, fixed scope and price, payment in two steps — 50% at the start and 50% at release. Budget reference: 2–5 million ₸ depending on the scenario and platforms; with a smaller budget the first version's scope is narrowed to what matters most — the price tag doesn't inflate.
Brief: scope boundaries
An important detail of the format: at the brief we record a separate list of what is NOT in the MVP.
Clickable prototype
A prototype of the key screens comes before development starts — changes on mockups cost a fraction of changes in code.
Sprints with a live demo
Development then runs in two-week sprints, each ending with a live demo: you see the product take shape and can correct course.
Typical scope mistakes
The same mistakes appear in most first-version specifications:
- 35 screens in the first version: the product is designed "like the market leader's", though the leader grew those screens through years of data-driven iteration.
- "iOS, Android, and web at once": every platform adds development, testing, and maintenance scope — how much depends on the stack and the share of shared code — while one platform is usually enough to test the hypothesis.
- No analytics: the product is live, but what happens inside it is unknown; growth decisions are made blind.
- A complex role system before the first user: weeks of work on functionality nobody is there to use.
- An exotic tech stack: a fashionable technology without a talent market makes the product hostage to one team.
Checklist: deciding what goes into your first version
A quick self-check before the start. Take every feature on your list and ask four questions:
- Does the hypothesis get verified without it?
- Can the user still complete the core scenario?
- Can the feature be replaced by a manual process for the first month?
- Does it drag in a second platform or a heavy integration?
If a feature fails the check — it moves to V2. The exercise takes an hour and saves weeks of development.
