MVP development cost in 2026: how an honest estimate is built

Two projects in our portfolio differ in effort by almost an order of magnitude. Both contracts named the same service in the same words, and neither client overpaid. The difference is how much work was hiding behind that one word.

That hidden part can be taken apart, and here is how we do it.

Why the answer starts with «it depends»

Usually this is not evasion. The vendor genuinely does not know three things yet, and each of them moves the price more than the framework everyone argues about on the first call.

Integrations come first. We built a storefront for a wholesale flower supplier with card acquiring and a two way sync with the client’s accounting system, and that exchange turned out heavier than the catalogue itself. The state of your data comes second: an export filled in by hand over ten years is a separate project, and it surfaces in week two, long after the brief. Third is the people who decide. A project with one owner and a project with three approvers run differently on identical code.

Clients often say their case is simple. Sometimes it is. What makes a project simple is the absence of connections to other systems, and size has little to do with it.

Seven blocks that go missing from cheap quotes

Open the document and look for discovery, architecture, infrastructure and environments, integrations, stabilisation, release with documentation, and project management. None of these disappear because nobody wrote them down. Three outcomes follow. The vendor absorbs the work and loses money. They come back for more budget halfway through. Or they skip it, and six months later you are looking for somebody to take over a product with no documentation and no environments. The third outcome is the most common one.

A quote without those lines looks cheaper right up to the day that work starts anyway. And it always starts. Every time.

One number hides the risk, three numbers show where it sits

We estimate in three points: minimum, expected, maximum. Any quote can be checked against this in a minute. Ask how the scenarios were produced. If the pessimistic case is the optimistic case multiplied by a coefficient, you are looking at presentation, not estimation. In a genuine three point estimate the markup stays almost still while an integration doubles, and that gap is your proof that somebody counted. We once reviewed a quote where the scope was understated roughly threefold, and that story deserves its own article.

A calendar month holds 160 hours, real output is 120 to 130

The rest goes to calls, context switching, reviews and answering questions in chats. We plan from the smaller number, and that gives a rule which saves clients money. When the scope does not fit, there are exactly three moves: cut the scope, extend the timeline, decline the project. Promising dates calculated at calendar hours is the fourth move, and it ends in a missed deadline that you discover two months later.

Reference ranges for 2026

These are our working ranges, not a price list. Where you land inside them is decided during discovery.

Format	Timeline	Budget
Landing page with a form and analytics	2 to 4 weeks	from 50,000 to 150,000 roubles
Messenger mini app, one flow	3 to 6 weeks	from 150,000 to 400,000 roubles
Web app MVP with accounts and payments	6 to 12 weeks	from 300,000 roubles
Mobile application	8 to 16 weeks	from 500,000 roubles

The upper bound is almost always integrations. The lower bound is reachable when the design already exists and one person makes decisions. That combination is rare.

What can be cut, and what comes back as an invoice

A good example of cutting comes from a hackathon where we built a financial literacy game inside a bank’s mobile app for Gazprombank.Tech. Building everything in the time available was physically impossible, so we cut authentication, the server side profile and user rankings, and kept the daily session of five questions, a timer, coins and an explanation shown right after a wrong answer. We reached the final and placed fourth. The cut was the reason. It worked because we cut around the core. The core was the loop of playing, failing and understanding why, and authentication added nothing to it.

What comes back as an invoice six months later looks different. Data structure: reshaping a model that already holds live records costs more than getting it right once. Automated deployment, which feels unnecessary until the third release. And analytics tagging, because without events tagged from day one you cannot separate people who came from your own channel from cold traffic, and your launch numbers will be beautiful and useless.

When the budget is smaller than the estimate

Here a spike does the work: a small paid step that tests the main technical risk before anyone talks about the full budget (a few thousand roubles buys you the answer). A few days, priced at the lower bound, with a completion criterion written down in advance.

We do not name a fixed price with a deadline before that check. It sounds more cautious than clients would like, and it saves both sides from a project that stalls halfway.

We never reconstructed the economics of our own projects after delivery. How much of each budget was margin and how much went into rework, I honestly do not know, because we did not measure it. So everything above is a way to count effort. Calling it a proven model of profit would be a stretch.

Back to those two projects from the opening. They differed in how many external systems had to exchange data with them: the light one had none, the heavy one had card acquiring and a shop’s accounting system. So when you compare two proposals, compare the list of work each vendor intends to do. If you want a second opinion, send us the quote and tell us which line worries you most.