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

Our largest single invoice for a website is 450,000 roubles, roughly 5,000 dollars. Our smallest paid project was 30,000 roubles. Neither client overpaid. The difference is how many blocks of work were hiding behind the word «website».

Here is how the estimate is actually built, and why two quotes for the same brief can differ threefold.

Why the answer starts with «it depends»

Usually this is not evasion. Before the task is broken down, a vendor does not know three things, each of which moves the price more than the choice of framework.

Integrations. We built a storefront for a wholesale flower supplier with card acquiring, a two way sync with the client’s accounting system, plus point of sale and restaurant management platforms. From the outside it is «a catalogue with a cart». In hours, the data exchange took longer than the catalogue, because in the accounting system the product structure looks nothing like what the designer draws.

The state of your data. An export where products were entered by hand over ten years is a separate project, and it surfaces in week two, not during the brief.

Who decides. A project with one owner and a project with three approvers have different timelines for identical code.

Seven blocks that go missing from cheap quotes

When a client shows us a quote from another vendor, these are the lines that are usually absent:

1. Discovery and analysis, done before the start rather than guessed along the way.
2. Architecture. The data model is decided once and changed expensively.
3. Infrastructure and environments: server, domains, certificates, a staging URL.
4. Integrations. Every external system is its own project with its own surprises.
5. Stabilisation. Bug fixing always happens and is almost never budgeted.
6. Release and handover documentation, so the product can live without the vendor.
7. Project management: calls, demos, acceptance.

A quote without these lines looks cheaper right up to the moment the work starts anyway. We once reviewed an estimate for an eyewear marketplace with augmented reality try on: the scope was understated roughly threefold, and even the vendor’s pessimistic scenario sat below our trimmed optimistic one.

A single number is wrong by construction

We estimate in three points: minimum, expected, maximum. Not because we like tables, but because one number hides where the risk lives.

There is a quick way to test any quote. Ask how the scenarios were produced. If the pessimistic case is the optimistic case multiplied by a coefficient, that is cosmetics, not estimation. In a real three point estimate the blocks diverge differently: an integration can double, markup almost never does.

A developer month is not 160 hours

A calendar month holds about 160 working hours. Useful output is between 120 and 130. The rest goes to calls, context switching, reviews, and reading other people’s code.

We plan from real capacity rather than from the calendar, and that gives a rule that saves clients money. When the scope does not fit, there are exactly three moves: cut the scope, extend the timeline, or decline the project. Promising dates calculated at 160 hours is the fourth move, and it ends in a missed deadline.

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 exists and one person makes decisions.

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

A good example of cutting scope comes from a hackathon run by the Moscow mayor’s office. We built a financial literacy game embedded inside a bank’s mobile app for Gazprombank.Tech. There was no way to build everything in the time available, so we cut authentication, the server side profile and user rankings. We kept the daily session of five questions, a timer, coins, and an explanation shown immediately after a wrong answer. We reached the final and placed fourth.

It worked because we cut around the core rather than into it. The core was the loop: play, get it wrong, understand why. Authentication added nothing to that loop.

What comes back as an invoice six months later:

Data structure. Reshaping a model that already holds live records costs more than getting it right once.

Automated deployment. Manual releases feel like savings until the third one.

Analytics with source tags. If events are not tagged from day one, you cannot separate people who came from your own channel from cold users, and your launch numbers will be beautiful and useless.

When the budget is smaller than the estimate

The working instrument here is a spike: a small paid step that tests the main technical risk rather than a feature. Not «make it look good», but «connect to their system, read the data, produce the document, export the result». A few days, priced at the lower bound, with a completion criterion written down in advance.

A spike answers the question that quotes usually disagree about: whether access to the system the product is built around is achievable at all. After it, the range narrows and the money conversation runs on facts.

We do not name a fixed price with a deadline before the spike. It sounds less confident than «a month», and it saves both sides from a project that stalls halfway.

If you want to sanity check any quote you have received, ask for three things: a breakdown by blocks, the list of assumptions, and a three point estimate.

Message us on Telegram