Product scope
What does an MVP app actually need?
A first release fails far more often from being wide and unfinished than from being narrow. An MVP is not a cut-down version of everything — it is one workflow taken all the way to a real outcome, with the rest deferred on purpose.
Most first releases are not too small. They are too wide. Five workflows are each built to roughly two-thirds, nothing is finished, and the product cannot be given to a real user because every path they might take runs out of road somewhere.
Start from the one job
Before scoping features, state the single job the application exists to do, phrased as an outcome rather than a screen: a customer submits a request and receives a confirmed booking; a field team records an inspection and the office sees it immediately; a member subscribes and gets access to what they paid for.
That sentence becomes the boundary. Every proposed feature is measured against it — does this stand between the user and that outcome, or is it adjacent value that can arrive in the release after?
In the first release vs deferred
What almost always belongs in version one
- The core workflow, complete: entry point, validation, the action itself, the confirmation, and what happens when it fails.
- Accounts and permissions, if the product has users with different rights — retrofitting an authorisation model is one of the most expensive changes there is.
- A data model that reflects the real domain, because everything after version one is built on it.
- Error handling that tells the truth, plus enough logging to reconstruct what happened when a user reports a problem.
- Accessibility and performance basics, which are properties of how it is built rather than a later audit.
What can usually wait
Deferral only works when it is a decision with a reason, recorded somewhere. Otherwise it turns into an undocumented gap discovered in week three of use.
| Deferred | Why it can wait | Bring it forward when |
|---|---|---|
| Configuration and settings | Hardcoded values are faster to build and easier to change than a settings interface | Two customers genuinely need different values |
| Reporting dashboards | The data can be exported and analysed elsewhere at first | A recurring decision depends on the same view every week |
| Additional integrations | Each one adds a dependency, a failure mode and a support burden | Manual re-entry is costing real hours or causing errors |
| Secondary workflows | Real, but not required to prove the core outcome | The first users hit them repeatedly in normal work |
| Bulk and admin tooling | Low volumes can be handled directly at first | Volume makes manual handling slow or risky |
Sequencing after launch
The order of releases matters more than the contents of any one of them. Widening before hardening produces a product that is broad, brittle and increasingly expensive to change.
Prove → harden → widen → systemise
Viable has to mean viable
The word doing the work in minimum viable product is viable. A release that a user cannot rely on has not tested the idea — it has tested their patience, and the feedback it generates is about the defects rather than the concept.
That is why the platform decision matters early. A first release built on an architecture that cannot carry accounts, state and workflow will be rebuilt rather than extended, which is the comparison drawn in PWA vs native app and in our application and PWA development service.
Narrow and finished beats wide and nearly working, every time. The first is a product; the second is a status report.
Frequently asked questions
- What is a minimum viable product in app development?
The smallest release that lets a real user complete a real outcome and gives the business genuine evidence about whether the product works. Viable is the operative word: it has to be usable in production, not a demonstration.
- How long should an MVP take to build?
Scope should be set so the first release lands in weeks rather than quarters. If the plan runs beyond roughly three months before anyone uses it, the scope is describing a full product with an optimistic label.
- What should never be cut from a first release?
Anything that makes the product unusable or unsupportable in production: authentication and permissions where accounts exist, a sound data model, error handling, accessibility, and enough logging to diagnose what happened. See app authentication and user account architecture for where that line sits.
- Should an MVP include integrations?
One, if the workflow genuinely depends on it. Each additional external system adds a failure surface that has to be designed, monitored and supported, which is discussed in APIs and integrations in modern applications.
- What is the difference between an MVP and a prototype?
A prototype answers a design or feasibility question and is then discarded. An MVP runs in production with real users and real data, and the code is expected to survive into the next release.