“Should we build an MVP or the full thing?” is usually asked as a budget question. It’s really a question about what your first release has to prove, and the answer changes depending on whether you already know your users need this.
What an MVP actually is
A minimum viable product is the smallest thing you can build that still does one real job for real users. Not a demo, not a mock-up — something people can actually use, that happens to do less.
The term has been stretched to mean “cheap and half-finished,” which is why it gets a bad reputation. A good MVP isn’t unfinished; it’s narrow. Every feature it does have works properly.
When an MVP is the right call
- You’re guessing about demand. If the honest answer to “will people use this?” is “we think so,” you’re buying information, and the cheapest information is a small real release.
- The feature list came from a brainstorm. Long wishlists assembled before anyone used anything are mostly untested assumptions. Shipping narrow sorts the real ones from the rest.
- You need something to show. To investors, a partner, or a first customer — a working narrow thing beats a polished deck.
When going straight to the full build is right
Sometimes the MVP advice doesn’t apply, and pretending otherwise wastes a release:
- You’re replacing something people already depend on. If your team currently runs on a system and the new app has to take over, a partial replacement isn’t usable — it’s two systems.
- The core job can’t be done partially. Some workflows only make sense end to end. Half a payroll run is not a smaller payroll run.
- Demand isn’t the question. When you already know the need — because you’re living it every day — you’re not buying information, and a deliberately narrow v1 just delays the thing you already know you need.
The budget math
Say you have a fixed amount to spend. Two ways to spend it:
All of it on v1. You get the most features, and you find out whether the assumptions behind them were right after the money is gone. If they were, great. If two of the five big features go unused, you paid full price for both.
Roughly half on v1, half held back. You ship narrower, learn which features people actually reach for, and spend the rest on those. You also keep the ability to respond to something you couldn’t have predicted — which, in our experience, is most of what the first month of real usage produces.
The second is usually better value, with one condition: the held-back half has to actually exist. Splitting the budget and then spending the reserve elsewhere gets you the narrow version permanently.
What to cut, and what never to cut
Safe to leave for v2: settings and preference screens, admin conveniences, bulk actions, reporting and exports, onboarding flows, edge-case handling for situations that happen monthly rather than daily, and anything whose absence you can cover manually for a few weeks.
Not safe to cut, ever: the one job the app exists to do, authentication and permissions, anything touching the integrity of your data, and basic security. These aren’t features — they’re the floor. A narrow app that loses data isn’t an MVP, it’s a liability.
How we scope a first release
We start from the single job v1 has to do, then work out what genuinely cannot be removed without breaking it — and we’ll tell you when we think the MVP route is wrong for your situation rather than selling you a smaller project by default. Timelines for either path work out roughly as described in our post on app build timelines.
Tell us what you’re building — or read more about how we approach app development.