What Is an MVP and How to Build One: Types, Scope, Timelines, Metrics

An MVP (Minimum Viable Product) is the smallest version of a product that lets you test the main demand hypothesis: is there a problem, does the product solve it and are people willing to pay for it. A good MVP gives you the most knowledge about the market at the lowest cost. Sometimes it’s a working app with one feature, and sometimes it’s a landing page or a manual service without a single line of code.

This article is for founders, product managers and heads of IT companies in Kazakhstan who are launching a new product or line of business. We cover what an MVP is and isn’t, six types of MVP with examples, how to define scope, stages and timelines, validation metrics, the specifics of the Kazakhstan market and the mistakes that eat up the budget.

What an MVP really is

The term was popularized by Eric Ries in his book The Lean Startup. The core idea: a product is built through a “build, measure, learn” loop, and an MVP is the shortest way to complete that loop for the first time.

The key word in the acronym isn’t “minimum” but “viable.” An MVP must deliver real value to the user; otherwise you’ll be testing testers’ patience, not demand. The second key concept is the hypothesis. An MVP is built not around a list of features but around one question whose answer determines the product’s fate. For example: “Heads of IT studios will pay for automatic client reporting because they currently spend half a day a week on it.”

If you can’t state the hypothesis in one sentence, it’s too early to build an MVP. First, talk to potential customers and understand what problem you’re solving.

What an MVP isn’t

There’s a lot of confusion around MVPs, and it’s costly.

An MVP isn’t a sloppy first version. A product with bugs and a clumsy interface tests not demand but willingness to put up with bugs. You can cut scope, but not the quality of the key scenario.

An MVP isn’t a cut-down version of everything you planned. If you take a plan with ten features and build each of them halfway, you get ten half-features, not an MVP. The right approach is to build one feature completely.

An MVP isn’t a prototype for investors. A pitch deck and beautiful mockups don’t show how real users behave.

An MVP isn’t the final product. Some of the code and decisions will be thrown out or reworked after the hypothesis is tested. That’s normal and should be planned for in advance.

An MVP isn’t necessarily software. If a hypothesis can be tested without development, it should be tested without development.

Types of MVP and examples

The type of MVP is chosen based on the hypothesis, not on the team’s habit of writing code.

MVP type	How it works	What it tests	When it fits
Landing page	A page describing the product with a request or pre-order form	Interest in the offer and willingness to leave contact details	You need to quickly test the value proposition and channels
Concierge MVP	The team provides the service manually, and the customer knows it	The value of the result and willingness to pay	Services, B2B, complex processes
Wizard of Oz	The customer sees an interface, and the team does the work behind it manually	Willingness to use the product in its familiar form	Automation and AI services before complex development
No-code	The product is assembled on ready-made platforms without programming	Usage and retention with real traffic	Simple logic, a small number of users
Clickable prototype	Interactive screens without a backend	Clarity of the scenario and interest in interviews	Complex interface, B2B demos
One key feature	A real product that does one thing well	Retention and payment	The hypothesis is confirmed and needs testing in real use

Well-known examples. Before full development, Dropbox showed a video of how file syncing would work and gauged interest by the audience’s reaction. Zappos’s founder started by posting photos of shoes from local stores on the website and buying the pair himself when an order came in. Both cases tested demand before building expensive infrastructure.

An example for an IT company. A studio wants to build a service for automatic client reports. Concierge MVP: a manager manually compiles a report from the tracker and sends it to five clients once a week. If clients read it, ask questions and are willing to pay, the next step is a product with one feature: automatic compilation of the same report.

A word on no-code. Builders let you assemble a working product in days, and for testing a hypothesis that’s often the best choice. But they have a ceiling: complex logic, load, integrations and data storage depend on the platform’s capabilities. If a no-code MVP confirms demand, the product is usually rewritten, and that should be built into the plan upfront rather than treated as a failure.

We covered how to test demand in two weeks, even before an MVP, in How to validate demand for an IT product before development.

How to define MVP scope

MVP scope is defined by one key scenario. Here’s the order of work.

1. Formulate the hypothesis. Who the customer is, what problem they have, what result they’ll get and what they’ll pay for.
2. Describe the key scenario. The user’s path from sign-in to the result they came for. It’s usually five to ten steps.
3. Cross out everything that isn’t part of the scenario. Settings, roles, reports, notifications, integrations: each feature has to prove that the scenario doesn’t work without it.
4. Replace automation with manual work. A spreadsheet replaces the admin panel, an employee replaces moderation, a daily export replaces a complex integration.
5. Keep analytics. Key scenario events must be recorded from day one; otherwise the MVP won’t measure anything.

To keep the feature debate from dragging on for weeks, it helps to split the list into two columns right away.

Usually in the MVP	Usually can wait
The key scenario from sign-in to result	Secondary scenarios and edge cases
Simple sign-in by email or phone	Complex roles and access permissions
Data storage and backups	A full admin panel: a spreadsheet or manual work replaces it
Analytics events for the key scenario	Detailed dashboards and reports
A way to get paid or confirm willingness to pay	Automatic billing with discounts and plans
A channel for communicating with the user	A notification center, email campaigns, in-product chat

What moves scope the most is the number of user roles, payments, integrations with external systems and the choice between web and a mobile app. How each of these factors affects effort and budget is covered in How much an MVP costs in Kazakhstan in 2026.

Stages and timelines for building an MVP

Timelines depend on the type of MVP and its scope, so below are reference points by stage, not promises.

Stage	What happens	Approximate timeline
Research	Customer interviews, formulating the hypothesis and decision thresholds	One to two weeks
No-code validation	Landing page, prototype or concierge format	From a few days to a few weeks
Analysis and design	Key scenario, screens, analytics events	One to three weeks
Development	One key feature, sign-in, data storage, a basic admin panel	From a few weeks to a few months
Testing and launch	Testing the key scenario, publishing, first users	One to two weeks; longer for mobile apps due to app store review
Measurement	Data collection, user interviews, a decision	Several weeks of real use

The minimum team for an MVP with development is a person responsible for the product and the hypothesis, a designer, one or two developers and testing of the key scenario. Roles can be combined, but combining the product owner role with development is risky: then feature decisions are made by someone more interested in writing code than in testing the hypothesis.

The last stage is often forgotten. Launching an MVP is the beginning of validation, not the end. The decision to continue is made based on several weeks of data, not on first feedback.

Metrics: how to know the MVP worked

The main rule: thresholds are set before launch. If you collect data first and then decide what counts as success, any numbers will look encouraging.

Metric	What it shows	The question it answers
Conversion to the key action	How many visitors completed the main scenario	Is the product clear and needed from the first try
Activation	How many new users got their first result	Do people reach the value
Retention	How many come back after a week and a month	Does the product solve a recurring problem
Willingness to pay	Pre-orders, payments, signed pilots	Is there a business, not just interest
Qualitative signals	What users say in interviews and what they ask for	Why the numbers are what they are and what to change

How many users you need. For a B2B product at the start, a few companies that actually use the product in their work are enough, plus in-depth interviews with them. For a mass-market product you need enough traffic to see differences between channels and cohorts, and what matters here isn’t the number but that users came from beyond the founder’s circle of acquaintances. Friends and colleagues give inflated ratings and distort the test.

Sign-ups, likes and compliments at a demo are weak signals. Strong signals are repeat usage, payment and the user being upset if the product disappears. When strong signals become stable and grow without manual effort from the team, the conversation is already about product-market fit; more in Product-market fit: what it is and how to tell if you have it.

MVPs in Kazakhstan: market and channels

The Kazakhstan market is smaller and denser than the markets English-language guides are written for. That’s both a limitation and an advantage. The limitation: a narrow B2B niche may have only a few hundred potential customers, and every failed contact is noticeable. The advantage: you can reach these customers personally, through referrals and industry communities, and get feedback quickly.

For an MVP, this means a few practical things. The concierge format and pre-sales work especially well because customers are used to personal communication. WhatsApp is a natural channel for a manual service and feedback: many Kazakhstan customers are more willing to reply in a messenger than to fill out a form. For products sold to mass-market buyers, when testing willingness to pay, it’s worth accounting for familiar local payment methods, including Kaspi. Connecting any payment provider requires a contract and verification, so at the start, payment is often replaced by an invoice or manual payment collection.

Kazakhstan context. If your MVP collects users’ personal data and it matters to you or your clients to store it in Kazakhstan, this affects your choice of hosting and no-code platforms from day one: many foreign builders store data outside the country. Moving after launch costs more than making the right choice at the start. Bilingualism is also worth planning for in advance: if your audience speaks Kazakh and Russian, check whether the MVP already needs an interface in both languages.

We described which channels work for a SaaS product’s first customers in GTM for SaaS in Kazakhstan, and the specifics of launching a mobile product in our article on bringing a mobile app to the Kazakhstan market.

Mistakes when building an MVP

Starting with development. The most expensive mistake. If the hypothesis can be tested with a landing page or a manual service, code can wait.

No hypothesis and no thresholds. The team launches the product “to see what happens,” and any result is interpreted as success.

Too many features. Every extra feature extends the timeline and blurs the conclusion: it’s unclear what worked and what didn’t.

Skimping on the quality of the key scenario. A user who hits an error on the third step won’t come back, and you’ll conclude there’s no demand.

No analytics. Without events in the key scenario, the MVP turns into the team’s opinion of how things went.

A mobile app where the web would do. Two platforms and app store review lengthen the path to the first data.

Measuring on your own people. If the first users are the founder’s friends, colleagues and followers, the data will be too optimistic. At least part of the audience should come from the channels through which the product will be sold going forward.

No plan after the MVP. What to do if the hypothesis is confirmed and what to do if it isn’t should be decided in advance so the data turns into action.

How we do it

We start with a diagnostic of the idea: we formulate the hypothesis, describe the customer and the key scenario, and set decision thresholds. If the hypothesis can be tested without code, we do that first. Then we design and build an MVP with one key feature and analytics from day one, launch it with the first users and, together with the team, make a data-driven decision: develop it further, change direction or stop.

How the work is organized, its stages and what the result includes are described on our service page for MVP development and IT product launch.

Terms in plain words

MVP (Minimum Viable Product)

A version of the product sufficient to test the main demand hypothesis with real users. It keeps you from spending the budget on a product the market doesn't need.

Hypothesis

A testable assumption about customers and the product, for example 'heads of IT studios will pay for automatic client reports.' An MVP is built around one main hypothesis.

Concierge MVP

A format where the team manually provides the service the product will later perform. The customer knows people are doing the work. It tests value before development.

Wizard of Oz MVP

A format where the customer sees the product's interface while the team does the work behind it manually. It tests whether people are willing to use the product without expensive automation.

No-code

Platforms where an application is assembled from ready-made blocks without programming. They suit quick idea testing but are limited in scaling and customization.

Clickable prototype

An interactive mockup of the product whose screens you can click through like a real app. It tests clarity and interest, but not real usage.

Retention

The share of users who come back to the product after a day, a week or a month. The main signal that the product solves a real problem.

Conversion

The share of people who move from one step to the next: from visitor to request, from request to payment. It shows where the product loses customers.