MVP development: how to launch a product quickly and without overspending

Most products fail not because of bad code but because they solve a problem nobody is willing to pay for. A minimum version lets you test that in weeks and for a reasonable sum, not in a year and with your entire budget.

This article takes a practical look at MVP development: what counts as a minimum product, which format to choose, how to cut unnecessary features, which metrics to watch after launch and what the first version costs. No theory for theory's sake: just numbers, timelines and common mistakes.

What an MVP is, and what it isn't

An MVP (minimum viable product) is the simplest version of a product that solves one key user problem well enough that people are willing to use it and pay for it. The key word is viable. It's not a mockup or an investor demo, but a working product with real users and real data.

What an MVP is not

• Not a half-baked version. One feature done well beats ten done halfway: users can't tell a “minimum product” from a “bad product”.
• Not a prototype. A clickable prototype tests whether the interface makes sense; an MVP tests whether people will pay and come back.
• Not a stripped-down copy of the final product. It's a separate slice: a complete user journey through one scenario, not 30% of each of ten.
• Not throwaway code. If the architecture isn't built for growth, you'll have to rewrite everything after a successful test and lose six months.

A good test: phrase your hypothesis as “We believe that [audience] will [action] because [reason]. We'll know we're right if [metric] reaches [value] within [timeframe]”. If you can't write the hypothesis this way, it's too early to write code.

MVP formats: from a bot to a platform

The same business can be tested with products of very different scale. Often the cheapest way to test the first hypothesis is in Telegram: users already have the messenger, there's no sign-up, and payment takes two taps. Compare the formats:

Choose the format based on the use case, not on trends. If users come back once a month, they don't need an app from the store; a website or a Telegram Mini App will do. If the product is used daily, with push notifications and geolocation, it makes more sense to plan for a mobile app or PWA from the start. We compare these options in PWA vs. mobile app.

How to choose features for the first version

The most expensive part of an MVP isn't what you built, it's what you built for nothing. Choosing features is the main work before development begins.

Step 1. One key scenario

Describe the user's path from first touch to getting value. For a services marketplace: the customer describes a task → receives responses from providers → chooses one → pays → leaves a rating. Anything not on this path is a candidate for version two.

Step 2. Manual operations instead of automation

At launch, a lot can be done by hand: moderation, matching providers, refunds, complex analytics. Automate what has become a bottleneck, when there are dozens of operations a day rather than two a week.

Step 3. Honest prioritization

• Must: without it the scenario can't be completed (catalog, ordering, payment, notifications).
• Should: noticeably improves the experience but doesn't block launch (filters, favorites, promo codes).
• Could: nice to have (themes, referral program, gamification).
• Won't: deliberately postponed (multilingual support, custom chat, advanced analytics).

Rule of thumb: if there are more than 7–10 features under Must, it's no longer an MVP. This selection is easiest to do right in the technical specification; we cover how to structure one in our article on how to write a development spec.

How much an MVP costs and what drives the price

The honest answer to “how much does an MVP cost” is anywhere from 60,000 ₽ for a bot to several million for a platform with mobile apps. The prices in the table above are for reference; an exact cost can only be given once the technical specification is worked out. The final estimate depends most on:

1. Number of roles. Customer and administrator is one level of complexity; customer, provider, moderator, dispatcher and accountant is a different story.
2. Platforms. Web, iOS and Android are three interfaces, even with a shared React Native codebase.
3. Payments. Accepting payments is simple; escrow, split payments, provider payouts and fiscal receipts are a separate block of work.
4. Integrations. Every external system (1C, CRM, warehouse, maps, telephony) adds days and risk, especially if it has no proper API.
5. Data requirements. 152-FZ (Russia's personal data law), hosting on your own servers, an isolated network, action auditing.
6. AI features. RAG over company documents or multi-agent logic require dedicated design work and testing of answer quality.

You can save on breadth, but not on the quality of the key scenario. Cutting the number of roles, postponing one platform, or replacing a complex integration with a Google Sheets export for the first few months is fine. Skimping on payment testing is not. Benchmarks for all services are collected on our development pricing page.

Turnkey MVP development: stages and timelines

Turnkey MVP development for a platform usually fits into 8–12 weeks. Here's how the time is split on a typical project of this size:

For a bot or Mini App, the same stages shrink to days; for a mobile app, they stretch to 8–14 weeks, with App Store and Google Play review on top. A real example: our home services marketplace, with a web version and iOS and Android apps, reached MVP in 9 weeks and then kept evolving in sprints without rewriting the architecture.

Metrics: how to tell if your MVP worked

Pick your metrics before launch; otherwise any result will look “not bad” afterwards. The minimum set:

• Activation: the share of new users who completed the key scenario (placed an order, booked, got an answer).
• Retention: how many came back after 7 and 30 days. For daily-use products, this is the main signal.
• Paid conversion: how many users paid at least once.
• Unit economics: acquisition cost versus revenue per user; for a marketplace, also liquidity (the share of orders that found a provider).
• Qualitative signal: 10–15 interviews with early users about what they liked, where they got stuck and what they'd pay more for.

Event analytics belongs in the first version, not “later”. Every step of the key scenario should be tracked; otherwise a month later you'll know users are leaving but not where.

MVP mistakes in startups and corporate projects

A startup MVP and a pilot inside a large company go wrong in different ways, but the causes are similar:

If you're planning a two-sided market, start with our article on how to build a marketplace: it covers the chicken-and-egg problem in detail and which side of the market to attract first. And to see how we design platforms that grow without rewrites, visit our platform and marketplace development page.