What an MVP should cost, and how to tell if yours is one

$30,000 – $46,000 for a first version of the marketplace this page prices: customers browsing local providers, booking one, paying in the app, and messaging afterward, on iPhone and Android, with the providers managing their own availability. The full version of that same app is $37,000 – $57,000.

$37,000 – $57,000

Everything described, 14–21 weeks

$30,000 – $46,000

The first version, 13–19 weeks, 19% less

Your app isn’t this app. Fewer kinds of user, no payments, one platform, and the number moves. Run your own idea through it and edit the description until it matches what you’re building. The first-version figure comes back alongside the full one.

Because this app carrying no features at all, on both phones, with nothing drawn and nothing built behind it, still costs $14,000 – $21,000. That’s the floor under it, and nothing you cut from a feature list touches it.

The floor covers working out what’s being built, a set of screens that look like one product instead of nine, the navigation between them, the environments it runs in, a bare API, and getting through app store review. Sign-in is not in there. That one is a feature and it costs like one. Every item that is in there is needed at full scope and needed at half scope, and none of them halve when the feature list does.

What people expect a first version to be

A fifth of the app for a fifth of the money. Ship it in a month, learn something, spend the rest later.

What the arithmetic gives you

19% off and a week sooner: $30,000 – $46,000 over 13–19 weeks, against $37,000 – $57,000 over 14–21 weeks.

Which is why speed is the wrong reason to build one. The reason is information: you watch people use it, then spend the rest of the budget on what you saw instead of what you assumed.

The features you could learn about later, or more cheaply, or by hand. On this marketplace the estimator takes one out and cuts the other one down.

• 01

  Chat or messaging: messaging is rarely what proves the product works

• 02

  Search and filtering: simple filtering instead of full indexed search

Messaging is the bigger of the two at about $8,000, and it comes out because a marketplace that nobody books on doesn’t need a place for people to talk. Email and a phone number carry a first release. If bookings happen and both sides then want to talk without handing out phone numbers, you’ve learned something worth paying for.

Search shrinks instead of disappearing. Filtering a short list is a different job from indexing a long one, and until there’s a long list nobody can tell the difference. That’s the useful kind of cut: the same feature, at a size that matches the number of people using it.

The thing the app is for, and the plumbing everything else stands on. Cutting either produces something cheaper that answers nothing.

What people cut first

Polish. The screens stop matching, the empty states go, the error messages get written by an engineer at five o’clock. It saves very little and it costs you the answer, because people who bounce off a rough first version don’t come back for the good one.

What the estimator cuts first

The features that get better once real people have used the thing: chat or messaging, then search and filtering. Both are cheaper and better built in month three, and neither one tells you whether anybody will book anything.

Ask what shipping it could prove wrong. If there’s no answer, you’ve described phase one of a plan, which is a fine thing to build and a different thing to budget.

• 01

  Name the belief. “Providers will keep their availability up to date without being chased.” Write it down before anybody prices anything.

• 02

  Say what result would change your mind, and by when. Twenty providers, four weeks, half of them still current at the end.

• 03

  Cut every feature that isn’t needed to run that test, then check the remainder against the floor. If it still costs most of the full build, the belief is probably too big to test in one go.

Run the marketplace above through that and it comes out borderline. $30,000 – $46,000 against $37,000 – $57,000 is about four fifths of the full build, which by the third item is a sign the belief is too big to test in one go: “will a two-sided market work” is really two questions wearing one coat. Cheaper first version, one side at a time. What belongs in a $50,000 budget covers the other direction, where the number comes first and the scope has to fit it.

Two things, and neither one is on your feature list. Cutting everything the estimator was willing to cut saved $9,000. Both of these beat it.

+$11,000

Two separate apps instead of one covering both phones: $46,000 – $70,000

−$10,500

A working system already behind it: $29,000 – $44,000

Building twice, once for each phone, costs $11,000 more than building once for both, and your users can’t tell the difference. That decision gets made in a meeting, sometimes by whoever is loudest, and it moves more money than the whole feature conversation does.

The other one is a fact about you instead of a decision. If something already works behind the app, this build is $29,000 – $44,000 instead of $37,000 – $57,000. That’s the largest saving available anywhere on this page, and it’s the one founders most often leave out, which is why saying it in the brief is worth more than an afternoon of trimming features.

Feature cuts still matter, they’re just smaller. Removing messaging saves $8,000, launching on one phone saves $3,000, and turning up with the screens already drawn saves $5,000. Shrinking a feature saves less than removing it, though not in proportion: the smaller it gets, the more of the scaffolding around it gets reused. How the estimate is put together shows where the rest sits.