Development

MVP in 2026: Real Timelines, Real Budgets and What to Cut

MVP no longer means cheap and rough. A weak prototype today produces a false negative and buries a workable idea. Here are four MVP tiers with prices and timelines, a framework for cutting scope, and the parts no budget justifies removing.

The Veltos.Tech team13 May 202614 min read

In short

A typical MVP budget on the Russian market in 2026 runs 700,000 to 3,500,000 RUB. A no-code version ships from four weeks, an MVP on ready components in six to ten weeks, a custom cross-platform product in three to four months, and a complex one with integrations and payments in four to six. Veltos.Tech starts web applications at 300,000 RUB and mobile apps at 500,000 RUB.

What an MVP means in 2026 and why cheap and rough became dangerous

The classic MVP definition was written when a digital product was itself a novelty. Users forgave clumsy interfaces because there was no alternative. In 2026 the situation is inverted: everyone carries a dozen polished apps, and the bar for "acceptable" is set by those, not by your niche competitors. A product that looks like a draft is dismissed within fifteen seconds, before the user ever reaches your value.

That produces the risk founders underestimate most: a bad MVP returns a false negative. You ship a raw version, see weak conversion and conclude the hypothesis failed. But what you tested was execution quality, not the hypothesis. The idea may well have worked, and you buried it along with an interface where nobody could tell what to tap. It is the most expensive way to save money: cash spent, conclusion wrong, direction closed.

The correct 2026 formula is a narrow feature set executed at production quality. One user job instead of five, but with a clear onboarding, tidy loading states, error handling and readable copy. Minimum does not mean unfinished, it means narrow. That distinction matters: a narrow product returns clean data, an unfinished one returns noise you cannot interpret.

Four MVP tiers: timelines and budgets

MVP prices vary enormously because the word covers four different products. The fastest tier is a no-code assembly: an interface from ready blocks, a spreadsheet-shaped database, automations through scenarios. That MVP ships from four weeks and costs a fraction of development. It is ideal for testing whether demand exists at all, and completely unsuitable when the hypothesis concerns experience quality.

The second tier is an MVP on ready components: real code, but built on interface libraries, off-the-shelf authentication, a payment provider and a managed database. Six to ten weeks for a genuine product with limited functionality that can grow without a rewrite. This is the most common format and, in our view, the most sensible one for a product intended to actually reach the market.

The third tier is a custom cross-platform product: bespoke design, mobile and web at once, your own back end, user roles. Three to four months. The fourth is a complex MVP with integrations: external systems, payments with verification, document workflows, data security requirements. Four to six months and the top of the budget. The market reference across all tiers is 700,000 to 3,500,000 RUB, and inside that range the price is driven mostly by how many external systems are involved.

MVP tier	Timeline	Budget (market)	Hypothesis it can test
No-code assembly	from 4 weeks	150,000-500,000 RUB	Whether demand exists and anyone pays at all
MVP on ready components	6-10 weeks	700,000-1,500,000 RUB	Whether the flow works and users come back
Custom cross-platform	3-4 months	1,500,000-2,500,000 RUB	Whether people pay for experience quality
Complex with integrations and payments	4-6 months	2,500,000-3,500,000 RUB and up	Whether the product fits a real workflow

MVP tiers: timeline, budget and the hypothesis each one fits

Cutting scope: three buckets of features

The framework that works is simple. Write down every feature that came to mind and sort it into three buckets. First: "tests the hypothesis", without which the experiment is meaningless. Second: "makes the product usable", without which nobody reaches the first bucket. Third: "later", everything else. The third bucket usually swallows 60-70% of the original list, and that is normal rather than a sign of a weak idea.

Work it through on a hypothetical example, a service that matches parents with tutors. The hypothesis: parents will pay for a vetted match rather than search on their own. Bucket one holds the request form, a tutor catalogue filtered by subject, trial lesson booking and payment. That is all. This chain is what answers whether there is money in the idea.

Bucket two holds the parts that do not test the hypothesis but block the path to it: registration, a homepage that explains itself, a booking confirmation notification, a "my lessons" page, cancellation. Bucket three: ratings and reviews, chat with the tutor, in-platform video calls, a tutor-side scheduling dashboard, a referral programme, a mobile app. Everything in bucket three feels mandatory, and every item in it can be handled by humans for the first three months.

The key technique is the concierge move: whatever is expensive to automate but cheap to do by hand for the first few hundred users. Matching can be done by an operator in a messenger, reports assembled in a spreadsheet, payment taken through a link. Automating a process you have not yet described is the fastest way to spend the budget on code you will throw away.

What no budget justifies cutting

Onboarding. Not a five-screen tutorial, but the first thirty seconds in which a person understands what this is, why it matters to them and what to do right now. Products with strong ideas fail here routinely: the user arrives, sees an empty screen with no explanation and leaves. Saving on onboarding costs tens of percent of conversion and thoroughly distorts the experiment.

Analytics from day one. An MVP exists to produce data, and a product without event analytics cannot answer the question it was built for. The minimum: a funnel from entry to the target action, drop-off tracking at each step, weekly cohorts and session recording. That is two or three days of work up front, and total blindness without it. Adding analytics after launch means losing the data from the most valuable period of all.

Payment, when the hypothesis is about money. There is a chasm between tapping an interest button and entering card details, and only the second number proves anything. If your question is "will people pay", taking payment belongs in bucket one, even as a simple payment link with no account area. Surveys and sign-up forms do not answer it: people sincerely want products they will not pay for.

Human support. At MVP stage it is not a cost line but a research channel: every message shows where the flow confuses people, which field is missing, which word reads wrong. A chat or email with a same-day reply produces more insight than any survey and costs considerably less. Automating support at this stage means switching off your main source of product understanding.

No-code or code, and what leaving no-code costs later

No-code wins so convincingly on speed and entry price that the question looks settled. Assembling a working service in four weeks with no developers is genuinely possible, and for demand validation it is often optimal. But no-code carries three hard limits that people discover later than they would like: performance under growth, the impossibility of non-standard logic, and total dependence on platform pricing.

Pricing deserves special attention, because no-code often gets expensive non-linearly. Platforms charge for database records, for executed automation runs, for active users. While those number in the hundreds the cost is invisible. At tens of thousands of records with active scenarios the monthly bill can reach a level where custom development would have paid for itself within a year. This is not an argument against no-code, it is an argument for pricing your projected volume rather than your current one.

The main hidden line is migration cost. Data moves out of no-code, logic does not: automation scenarios, access rules, formulas and interface all get rebuilt from scratch. On the market that means close to the full cost of a fresh build plus data migration work. So the no-code stage should be budgeted as an expense you will most likely write off, not as a first version that will keep evolving.

The practical rule we apply: if you are validating demand and prepared to throw the result away, take no-code, it is cheaper and faster. If you already know the product is needed and the question is how to build it, go straight to code on ready components. The middle path often turns out best: no-code for internal processes and admin, code for everything the user sees.

Budget lines beyond development

Development is usually 55-70% of the real launch budget, and founders routinely plan only that part. Design is its own line and takes 15-25% on an MVP: a product designer is there not for beauty but so that a narrow feature set does not look truncated. Analytics and tracking setup add a few more days. Infrastructure, meaning servers, database, domains, transactional email and monitoring, runs 5,000 to 40,000 RUB a month at the start.

For a mobile product the app stores join in: developer accounts, store listing materials, review passes and, in Russia, publishing to RuStore with its own requirements. Reserve two or three weeks for the first submission, since it rarely clears on the first attempt and a launch calendar without that buffer is fiction. Legal work sits separately: terms of service, a personal data policy, the required regulator notification, and an offer agreement to take payments.

The most underestimated line is the first three months after launch. An MVP does not end at release, it begins there: data arrives, gaps in the flow appear, and it turns out half the users take a different path. Budget 30-50% of the development cost for iteration. Without that reserve you get a product you cannot improve and data you cannot act on, and this stage is exactly where the value of the whole experiment comes from.

Design: 15-25% of budget, without it a narrow MVP looks unfinished.
Infrastructure and monitoring: 5,000-40,000 RUB a month at launch.
App stores: 2-3 weeks for the first submission, RuStore included.
Legal pack: offer agreement, data policy, regulator notification.
First three months of iteration: 30-50% of the development budget.

Success metrics defined before the build starts

The most common MVP failure is methodological rather than technical: the product ships, the data arrives, and nobody agreed in advance what success looks like. The interpretation then bends toward the desire to continue. So the numbers get written down before the build starts: what visit-to-signup conversion counts as sufficient, what share of users must return in week two, how many must reach payment.

A good metric is specific, automatically measurable and tied to money. "Users like it" is not a metric. "40% of registered users return on day seven" is. "Cost to acquire a paying user stays under 2,500 RUB against an average order of 4,000 RUB" is a metric you can make an investment decision on.

Define the stopping conditions too. If eight weeks after launch and three iterations the key metric has not moved, the hypothesis did not hold, and that is a normal, useful result which is precisely what the MVP was for. Knowing when to stop saves far more money than any development budget optimisation: a product without demand can be improved indefinitely, and that is the most expensive available way to avoid admitting the obvious.

Frequently asked questions

Can an MVP really be built in 30 days?

Yes, under two conditions. First, scope is reduced to a single user journey and the cutting decisions are made before the start rather than along the way. Second, you use ready components: authentication, payments, an interface library, a managed database instead of custom infrastructure. A month is enough for a web product with registration, the core flow and payment. What does not fit in a month: a mobile app for two platforms, integrations with external accounting systems, and anything that has to pass store review.

What does a mobile app MVP cost?

On the Russian market a cross-platform mobile MVP typically lands between 1,500,000 and 2,500,000 RUB over three to four months. Add payments, external system integration or sensitive data handling and the budget moves to 2,500,000-3,500,000 RUB and above. Veltos.Tech starts mobile development at 500,000 RUB, which buys a narrow product with a limited screen count. Budget publishing separately: developer accounts, store assets and two to three weeks of review cycles.

What if an investor wants to see a product and there is almost no budget?

Build a clickable prototype plus one genuinely working piece, rather than the whole product at half quality. A prototype in a design tool communicates the concept, costs little and takes one or two weeks. One working feature with real data proves the team can reach shipped code. Investors look at problem understanding and demand signals, not screen count. A landing page taking payment with a hundred real pre-orders is more persuasive than a half-finished app with twenty screens.

Does an MVP need a designer or is a template enough?

A template covers the visual layer but not the product layer: screen sequence, field composition, button copy, empty states and error handling. Those decisions determine whether the user reaches the target action. The practical compromise is to take a ready component library instead of a bespoke visual style and spend the designer time on flows and copy. That halves the design budget without creating the false-negative risk the whole MVP was meant to avoid.

What belongs in an MVP and what definitely does not?

In: one core journey end to end, registration, onboarding, event analytics, payment if the hypothesis is about money, and a support channel. Out: a flexible-permission admin panel, dashboards for every user type, built-in chat, push notifications, referral programmes, multiple languages, integrations built "for later", and a mobile app if the web version has not proven demand yet. Everything on the second list gets added once the metrics confirm the product is wanted at all.

Need a hand with this?

We do this work, not just write about it. Describe the task and we will scope it and send a staged estimate.

Discuss a project