Minimum viable product might be the most misused phrase in software. It gets used to mean a cheap version, an unfinished version, or whatever could be built with the money left over. None of those are what it means, and the confusion causes real damage to real projects.
An MVP is the smallest thing you can build that genuinely solves one problem for one group of people, well enough that they would be annoyed to lose it. Small in scope. Not rough in quality.
Minimum and Viable Are Both Load Bearing
The two halves pull in opposite directions and that tension is the entire point.
Minimum means you cut ruthlessly. Every feature is a cost, a delay, and a guess about what people want.
Viable means the part you keep has to genuinely work. A budgeting app that loses transactions isn't a minimum version of anything, it's a broken product. People won't forgive a core failure because you told them it was version one.
Most failed first releases got one of these wrong. Either they weren't minimum, so they took eighteen months and launched into a market that had moved, or they weren't viable, so they launched and nobody would use them twice.
Start From the Problem, Not the Feature List
The common mistake is beginning with everything the product could eventually do and trying to trim. That anchors you to the big version and every cut feels like a loss.
Work the other direction. Write one sentence describing the specific problem, for a specific person, that this product solves. Then ask what's the least you could build that solves it completely.
If you can't write that sentence, the scoping problem isn't really about features. It's that the product doesn't have a clear job yet, and building won't fix that.
A Test for Each Feature
For anything proposed for version one, ask whether the core problem is still solved without it.
- If yes, it waits. Not forever, just not now.
- If no, it stays. It's part of the minimum.
Applied honestly this removes a surprising amount. Things that almost always fail the test include admin dashboards, settings screens, onboarding tours, social features, multiple user types, and anything described as nice to have. Things that usually survive are the single core workflow, whatever makes that workflow trustworthy, and the simplest way to get someone using it.
When Forekala was scoped, flexible budgeting and reliable bank synchronization had to be there, because the product's entire claim was that it fit how a household actually manages money. Rewards and elaborate reporting were real ambitions that could wait, because their absence didn't stop the core promise from being true.
Decide What You're Trying to Learn
An MVP is an instrument for answering a question, and being explicit about the question changes what you build.
The questions are usually one of a few. Will anyone use this at all. Will they use it repeatedly. Will they pay for it. Can we deliver it at a cost that works.
These need different first versions. Testing whether people want the thing might only require a landing page and a waiting list. Testing whether they'll keep using it requires the real workflow, built properly, because habit forms around something that works. Testing willingness to pay means payment has to exist even if everything around it's manual.
Naming the question first prevents the most expensive kind of mistake, which is building a full product to answer something a much smaller experiment would've settled in a fortnight.
Sequencing That Keeps You Honest
Once the scope is set, how you build matters as much as what you build.
- Get one complete path working end to end before adding a second. A single workflow that functions fully teaches you more than six that are half finished.
- Put it in front of real people early. Not friends being polite. People with the problem.
- Build in increments you can actually use. Seeing working software every couple of weeks lets you change direction while changing direction is still cheap.
- Write down what you cut and why. This turns deferred features from lost arguments into a roadmap, which makes them far easier to leave out.
Do the Unscalable Version First
A useful trick when a feature looks expensive is to ask whether a person could do it manually for the first few months.
Matching two sides of a marketplace can be somebody with a spreadsheet before it is an algorithm. Onboarding can be a phone call rather than a guided flow. Reports can be assembled by hand and emailed. Moderation can be a human reading everything, because early on there isn't much to read.
This feels like cheating and it's one of the most reliable ways to ship early. You learn precisely what the automated version needs to do, because you've done the job yourself, and you avoid building an elaborate system around assumptions that turn out to be wrong. Automate a task once it's genuinely painful, not in anticipation of pain that may never arrive.
Where Scoping Usually Goes Wrong
- Building for a user who doesn't exist yet. Features for the enterprise customer you hope to land in year two.
- Copying a mature competitor. The product you're comparing yourself to has had years and a team. Its current feature set isn't your starting line.
- Confusing minimum with cheap. Cutting quality instead of cutting scope produces something that works badly at everything rather than well at one thing.
- Treating launch as the deadline. Launch is when you start learning. Spending everything to get there leaves nothing for acting on what you learn.
That last one is worth planning around explicitly. Reserve budget for the months after release, because the changes you make once real people are using it are usually the most valuable work in the whole project. We went through those numbers in How Much Does It Cost to Build an App.
What Should Never Be Cut
Scope gets cut. Some things aren't scope, and cutting them produces something that fails regardless of how good the idea was.
- Reliability in the core workflow. The one thing the product does has to work every time. Everything else can be rough.
- Not losing people's data. Recoverable from the user's point of view, always.
- Basic security. Passwords stored properly, connections encrypted, access controlled. Not a version two concern.
- Being usable without instruction. If people can't work out what to do, you'll learn nothing from watching them, because you'll only be measuring confusion.
- Some way to see what's happening. Even simple analytics. Shipping with no visibility means the whole point of shipping early is lost.
The distinction is between narrow and shoddy. A product that does one thing dependably reads as focused. A product that does five things unreliably reads as broken, and users don't distinguish between unfinished and bad.
Small Enough to Ship, Real Enough to Judge
A good first version is uncomfortable. It does less than you want, and you'll worry it's too thin. That discomfort is the signal that you scoped it correctly, because the alternative is spending a year building on assumptions nobody tested.
The whole sequence from idea through launch is covered in From Idea to Launched App, and this is the decision that sits at the front of it. Get the scope right and the rest of the project gets easier. Get it wrong and no amount of good engineering later will recover the time.
