MVP cost estimator

The output isn’t a budget. It’s a reference point you hold next to a real quote, so the conversation stops being about whether a number feels high and starts being about which line you disagree on. That shift is the whole value of the exercise.

Comparing it against a quote you have been handed

Set the inputs to match the brief you actually sent, not the product you imagine in eighteen months. Then compare structure before you compare totals. Take the vendor’s number, divide it by the hours in the table here, and see what hourly rate falls out. If that implied rate sits far below the market band for wherever the team is, you’re looking at hours nobody budgeted rather than efficiency. If it sits far above, ask what seniority you’re buying and on which lines.

A quote that lands inside this range and itemises differently is fine, and often better informed than the model. A quote that lands inside the range as one undifferentiated number isn’t. Ask for the six lines. A vendor who can’t defend a forty-hour QA line would rather you never saw it, and the reluctance is the signal.

The four lines that quietly go missing

Environment setup.Staging and production, CI, secrets management, migrations, seed data, preview deployments. Twenty to forty hours of engineering that appears in no design mock. If you’re told it’s included, ask which number it’s included inside. The answer is usually the build line, which is the line you were least equipped to check.

Third-party running costs.These are monthly, not one-off, and they begin before you have a single paying user. They’re not the vendor’s to pay, which is exactly why nobody mentions them until the first invoice arrives from somebody else.

Store and compliance overhead. The developer account fees are trivial. The privacy labels, the data safety form, the screenshots at every required size, the review notes and the first rejection are not, and none of it goes faster when you add people.

Maintenance from month one.Fifteen to twenty percent of build cost a year is the cost of the thing continuing to work, not a service upsell. Software that nobody maintains doesn’t hold still. It degrades, because everything underneath it moves.

What a suspiciously low number usually means

A bid at a third of everything else on your desk is rarely a discovered efficiency. It’s one of four things, and you can tell them apart if you ask.

It may be a narrower reading of the same words, login as one line rather than eleven, in which case the gap reappears as change orders in week six. It may be missing lines, most often QA, project management and infrastructure, absorbed rather than removed. It may be a seniority swap, where the people in the pitch aren’t the people on the branch, which is the failure mode to watch for when you’re running an offshore engagement. Or it’s a genuine rate difference, which is real and which we benefit from, and which still doesn’t explain a factor of four on its own.

The test that separates them costs one email. Send the low bidder the line-item table this tool produced and ask them to map their number onto it. A vendor who has thought about the work will disagree with specific rows and tell you why. A vendor who hasn’t will restate the total.

And then cut

If the number is bigger than the money you have, don’t compress the timeline. Compression doesn’t remove hours. It moves them into the bug budget at a worse exchange rate. Cut surfaces instead. Untick the admin dashboard and watch what happens to the total. For most early products a database client and a couple of scripts do that job for the first six months. That’s a real reduction in hours, and it’s reversible. A rushed launch isn’t.