MVP cost: what belongs in version one and what can wait

Quotes for the same MVP land anywhere between a few thousand dollars and a quarter of a million, and every one of them is honest about something different. Scope drives the number, not the hourly rate, and scope is yours to set. Here is what has to ship in version one, what safely waits, and how to work out your own range before you talk to anyone.

·5 min read·Jakub Dulas
MVP cost: what belongs in version one and what can wait

Ask four agencies to price the same MVP and the quotes will not be close. One counts two native apps, another counts a single browser workflow. Every one of them is telling the truth about something different, and the thing that differs is scope, not the hourly rate.

Scope is the one variable you control. Below is what has to ship in version one, what waits without hurting you, and the arithmetic you can do before the first call.

What an MVP is, and two things it is not

A minimum viable product is the smallest version that solves a user's problem well enough to find out whether anyone will pay for it.

Two misunderstandings wreck most first builds.

An MVP is not a prototype. A prototype is clickable with nothing underneath and exists to show an idea. An MVP runs, takes real users and real data.

An MVP is also not a stripped-down version of the finished product. You are not building everything badly. You are building one thing all the way through, so somebody can use it and pay for it.

If launching yours will not let you say “this works” or “this does not”, the scope was picked wrong.

Four things that have to ship

None of them can wait.

One workflow carried end to end. A user arrives with a problem and leaves with it solved, without anyone gluing steps together by hand.

Sign-in and basic roles. Two are enough, but without them you cannot test anything with real people.

A view into what is happening. Without it you cannot tell “nobody uses this” apart from “people use it and get stuck on step three”.

One integration with a system your user already lives in. A product that needs data retyped into it does not get opened twice.

Six things that can wait

These are what usually slip into scope and double the budget without changing the answer to your actual question.

Native iOS and Android apps. A browser is enough to validate, and two native platforms are two more projects.

Payment integrations. You will invoice the first customers by hand and learn more from the conversation than from a checkout funnel.

Multiple languages. If you do not know whether the product works on one market, a second one will not tell you.

SSO and enterprise sign-in. That arrives when the first large customer asks for it, not before.

Migration from whatever you run today. Expensive, slow, and it answers no business question.

A custom design system. Consistent looks are enough. A visual language of your own is a growth-stage investment.

Why the quotes spread so far apart

Three things move the number, and the hourly rate is not among them.

Platform count. Web is one project. Web plus two native apps is three.

Integration count. Every connection to somebody else's system is separate work, separate testing, and separate exposure to their next release.

Open or closed scope. A project with the feature list agreed before signing costs what it says. A project where scope gets settled along the way costs whatever it takes.

An agency quoting from the low end and one quoting from the high end can both be honest about two different products. Establish which one you are discussing before you compare figures.

The arithmetic you can do before the first call

Four questions and a sheet of paper.

How many platforms: browser only, or native apps as well? How many outside systems have to connect, counting the shared inbox? Does the product only display data, or does it change it? Do you have the workflow written down, or does it live in people's heads?

Browser, one integration, documented workflow puts you at the low end. Two to four integrations with the product writing back into live systems puts you in the middle. Native apps or compliance requirements put you at the top.

This will not replace a quote. It is enough to recognise a quote that was written without looking at your situation.

How long it takes and what actually slows it down

One workflow in a browser is usually two to three months of work. Every extra platform adds its own cycle. One agency in this space advertises production-ready startup MVPs in an 8 to 10 week window, which is the same order of magnitude.

The clock rarely stops on engineering. It stops on waiting: for a decision, for access to a system, for copy. One decision-maker on your side and answers inside 24 hours will shorten a project more than adding people on ours.

What happens when you get in touch

We start with scope, not price. The workshop runs a day or two and you leave with a feature list, flow mockups and acceptance criteria on paper, whether or not you work with us afterwards.

You talk to the owner, not a salesperson. If the workshop shows you do not need us, we say so and you pay for the workshop only. We credit its cost against the project if you sign within thirty days.

Your code sits in your repository from the first commit, so you can walk away and take all of it. Scope is fixed before signing, never during. The warranty covers repairs at no extra charge for twelve months.

We stay after handover. That is the part no tool and no fixed-price marketplace will sell you.

Questions & Answers(FAQ)

The smallest version of a product that genuinely solves a user's problem and lets you find out whether anyone will pay for it. It is not a reduced version of the finished product. It is one workflow built all the way through.

A prototype is clickable with nothing running underneath and exists to show an idea. An MVP runs, handles real users and real data. A prototype is built in a design tool. An MVP is built in code.

Three things move the number and the hourly rate is not one of them: how many platforms you need, how many outside systems have to connect, and whether the scope is agreed before signing or settled during the build. Two honest quotes can be far apart because they describe two different products.

Four things: one workflow carried end to end with no manual steps, sign-in with basic roles, a way to see what users actually do, and one integration with a system they already use. Everything else can wait for version two.

One workflow in a browser is usually two to three months, and each additional platform adds a cycle. The common delay is not engineering but waiting on decisions and system access from the client side.

Got a similar process on your side?

If something in this article sounds like your day-to-day - let's talk. We'll tell you plainly what can be improved, and what's not worth touching.