The most common reason software projects go over budget is not bad code, missed deadlines, or difficult developers. It is scope — specifically, building more than you need in the first release. A feature that feels essential in a planning meeting often turns out to matter less than expected once real users are involved. And by the time you find that out, you have already spent the budget building it.
This is the problem that minimum viable product (MVP) thinking addresses. Done properly, it forces you to make hard choices upfront about what your product actually needs to do — and what it can safely leave out until you have evidence it is worth building.
What is an MVP?
An MVP is the smallest version of your product that solves the core problem for real users and can be shipped to production without embarrassing yourself.
The "viable" in MVP matters. It does not mean a prototype or a mockup. It does not mean a system so stripped down that nobody would actually use it. It means a working product that delivers genuine value for at least one type of user — imperfect, limited in scope, but functional and releasable.
The goal of an MVP is not to ship quickly. The goal is to learn as cheaply as possible. You build a minimal version, ship it, and find out whether your assumptions about what users need are correct. That learning shapes what you build next. Without it, you are spending significant money developing features for imaginary users based on guesses.
What belongs in an MVP?
The features that belong in an MVP are the ones that directly enable a real user to complete the core workflow your product exists to support.
Start by identifying the single most important thing your product does. Not the most impressive feature, not the thing that differentiates you from competitors — the core action that a user comes to your product to perform.
For an invoicing tool, that is creating and sending an invoice. Everything else — automated reminders, client portals, multi-currency support, team roles, integrations with your accounting software — is secondary. If a user can create and send an invoice in your MVP, it is viable. If they cannot, it is not.
Once you have identified the core workflow, add only the features genuinely required to complete it. A useful test: ask whether removing a feature would prevent the core user from accomplishing the core task. If yes, it belongs in the MVP. If the answer is "not really, but it would be annoying," that feature can wait.
The essential supporting features
A few categories of features almost always belong in a first release, even if they are not the headline functionality:
Authentication and basic security. If users are logging in and storing data, you need a working, secure auth system. This is never glamorous, but skipping it creates technical debt that is expensive to retrofit.
Core data management. Users need to see, edit, and delete their own data. Read-only access in an MVP is almost never enough — people need to fix mistakes.
Basic error handling. The system needs to tell users when something goes wrong, and what to do about it. Silent failures are worse than obvious ones.
What does not belong in an MVP?
This is where most projects go wrong. The things that get added to MVP scope are usually not bad ideas — they are good ideas that belong in version two.
Admin tools and management interfaces. Internal dashboards, user management for the product owner, bulk operations — these are important eventually but rarely affect whether the core product works. In an early MVP, you can manage most of this directly in the database.
Reporting and analytics. Useful once you have meaningful data. In the first weeks of operation, you have almost none.
Multiple user roles and complex permissions. Start with one role. Add complexity once you understand how different users actually interact with the product.
Integrations with secondary systems. If your product needs to connect to a core system to function — a payment processor, for example — include it. If the integration is a convenience feature, cut it. Integrations are typically time-consuming to build correctly and straightforward to add later.
Mobile applications. If your product can work in a browser, ship the browser version first. A mobile app is a separate build with significant additional complexity. Validate the core product before committing to it.
Edge case handling. Build for the common case first. Edge cases — unusual inputs, uncommon workflows, specific scenarios that apply to 5% of users — are a legitimate concern, but not for a first release.
How do you draw the line between MVP and version two?
The practical difficulty is that nearly every feature feels necessary during planning. The people proposing features are not wrong to want them — they are usually imagining real user needs. The discipline is in sequencing: what does the product need on day one, versus what can be added once the core is working?
Three questions help draw the line:
Would a user refuse to use the product without this feature? If yes, it belongs in the MVP. If they would use the product but find it less convenient, it can wait.
Does this feature require the core product to exist first? If a feature can only be built after the core is working — reporting, for example, requires data to report on — it naturally belongs in a later phase.
Is this feature for a real user you are building for now, or a hypothetical user you might attract later? Build for the users you have or expect in the first three months. Do not design for users you might attract in year two.
When is the MVP done?
An MVP is done when one real user can complete the core workflow end-to-end without guidance.
Not when it is polished. Not when it handles every edge case. Not when the codebase is perfectly structured. When a person who did not build it can sit down, open it up, and do the thing the product is supposed to do — that is the bar.
This sounds deliberately low, and it is. The point of an MVP is to get real feedback before investing further. If you hold it to a higher standard than "it works for the core use case," you will keep adding features until you have effectively built version two — without the user feedback that should have shaped it.
After launch, watch what users actually do, not what they say they want. Where do they get stuck? What do they try to do that the product does not support? Which features do they use most, and which do they ignore? That usage data is worth more than any number of pre-launch planning sessions.
Where does scope creep come from?
Scope creep does not usually arrive as a single dramatic request. It arrives as a series of reasonable-sounding additions:
- "Can we just add export to CSV? It won't take long."
- "We should handle this edge case before we go live."
- "What if a user wants to do X?"
Each addition feels justified in isolation. But a project that starts as a three-month MVP becomes a six-month project when twenty small features are added. The resulting product is more complex, harder to test, later to market, and no better validated than the simpler version would have been.
The defence is a written scope document that gets reviewed whenever a new feature is proposed. Any feature not on the agreed list goes to a backlog, not into the current build — no exceptions during the MVP phase. This is not about being inflexible; it is about making explicit decisions rather than letting scope expand by default.
What does a good MVP scoping session look like?
The most valuable conversation you can have before development begins is a scoping session: defining the core workflow, listing what is in scope, and explicitly listing what is out of scope. That out-of-scope list is not a rejection — it is a prioritised backlog waiting for the evidence a real MVP will generate.
A good scoping session covers:
- Who is the primary user and what is the one thing they need to be able to do?
- What does the end-to-end flow look like for that user, step by step?
- What data does the system need to store, and where does it come from?
- What integrations are truly required for the product to function at all?
- What are we explicitly deferring, and why?
That last question is often the most revealing. If a team cannot agree on what to defer, they will not agree on scope either — and you will spend the development budget resolving those disagreements through code rather than conversation.
Getting the scope right before you build
At Clear Frame AI, I work through MVP scoping with clients at the start of every custom software engagement. Getting the scope right before development begins is one of the most cost-effective things you can do — it is far cheaper to cut a feature in a conversation than to remove it after it has been built.
If you are planning a software project and want an outside perspective on what your MVP should include, get in touch. It is usually a short conversation, and it is the kind of thing that pays for itself many times over before a line of code is written.