What an MVP costs, and what it should not include

Across the 27,169 project briefs we hold, 1,755 involve a mobile app and 1,535 involve a dashboard, portal or admin panel. Between them that is a substantial share of what people want built, and it is the category where the gap between the estimate and the eventual cost is widest — not because the work is unpredictable, but because the word minimum does a lot of unexamined work in the phrase minimum viable product.

The estimate is driven by surfaces, not features

The instinct is to count features. That is the wrong unit. The thing that actually drives an MVP's cost is how many distinct surfaces exist, where a surface is a combination of a user role and a place they use the product.

A marketplace with buyers, sellers and an administrator is not one product with three feature sets. It is three products that share a database. Each one needs its own screens, its own permissions, its own empty states, its own onboarding and its own way of going wrong. Adding a role late is close to the most expensive change available, because it touches the data model, the authorisation layer and every screen already built.

Those multipliers are approximate and they compound with everything else, but the shape of them is consistent: roles cost more than features, and nobody counts roles when they picture the product.

The three things always left out

Three pieces of work are absent from nearly every MVP brief we receive, and required by nearly every MVP at launch.

1. An admin interface. Somebody has to reset a password, refund an order, unblock an account or fix bad data. Without a screen for it, the answer is a developer with database access — which works for a fortnight and then becomes the bottleneck for everything.
2. Billing, if anyone pays. Taking a payment is easy. Handling a failed card, a refund, a plan change mid-cycle, a proration and an invoice someone's accountant will accept is not, and it is all required the moment real money moves.
3. Notifications. Email at minimum: verification, password reset, the thing-happened message. Each is small and there are always more of them than anyone listed.

Does it need to be an app?

This is the highest-leverage question in the category. A native app means two platforms, two review processes, two release cycles, device testing, store listings, and a permanent update obligation as operating systems move underneath you. It roughly doubles the surface area of the same product.

It is worth it when you need something the browser cannot do — background location, offline-first behaviour, hardware access, push notifications that genuinely must arrive. It is not worth it when the requirement, once examined, is that it should work well on a phone. A large proportion of app briefs are the second one wearing the first one's clothes, and the cheapest possible improvement to an MVP budget is noticing that early.

What minimum should actually mean

A useful definition: the MVP is the smallest build that lets you learn whether the central assumption is true. Everything else waits. That framing makes the cuts obvious, because most features fail the test immediately — they improve a product whose existence has not yet been established.

It also makes clear what cannot be cut. If the assumption is that people will pay, billing is in scope on day one and cannot be deferred. If the assumption is that two sides will find each other, both sides ship together and there is no version with only one. The cut list is determined by the question, not by what is easy to remove.

The failure mode to watch for is the MVP that includes everything anyone mentioned, delivered eight months late, launching into a market nobody tested. At that point it is not a minimum viable product; it is a full product built on an untested guess, which is the exact risk the approach was supposed to avoid.