Every founder has a clear idea of what they want to build. The problem is that the full vision is never the right thing to build first. Building the full vision costs hundreds of thousands of dollars and takes a year. Building the right subset of it costs tens of thousands of dollars and takes three months. The difference is knowing which subset to build.
This is what an MVP is actually for: not to save money, but to learn fast.
The definition that most founders get wrong
MVP stands for Minimum Viable Product. The word that gets the most emphasis is usually "minimum." But the word that actually matters is "viable."
A viable product is one through which a specific user can experience the core value proposition. Not a prototype. Not a mockup. A working product that does the one thing it is supposed to do, well enough that a real person can use it to get real value.
The minimum is defined by viability. The smallest version of your product that still delivers real value is the MVP. Anything that does not affect whether the product is viable or not is post-MVP.
The five questions that define your MVP scope
1. Who is the first user?
Be specific. Not "small business owners." "Freelance graphic designers in Australia with three to ten regular clients." The more specific your first user, the narrower and cheaper your MVP becomes.
2. What is the single thing they are trying to accomplish?
Not a list of things. The one thing. The core job to be done. Everything else is secondary.
3. What does success look like for that user in the first session?
Draw the critical path: from sign-up to the moment of value. Every step on that path is in scope. Everything else is not.
4. What is the minimum version of each step on the critical path?
Each step can be built at different levels of polish. Define the minimum that makes each step functional, not beautiful.
5. What would make a user not complete the critical path?
These are blockers. If a bug in step three prevents users from reaching step four, it has to be fixed. If a missing feature in step two is frustrating but users can work around it, it is post-MVP.
What always belongs in an MVP
Some things are genuinely non-negotiable in almost every software product:
Authentication. Users need to sign in and have their data belong to them. Even a basic email and password implementation is necessary.
Core user flow. Whatever the product is supposed to do, that thing needs to work. Reliably. End to end.
Error states. When something goes wrong, users need to see a helpful message, not a stack trace or a blank screen.
Basic data persistence. Users should not lose their work when they close the browser.
Security basics. Even in an MVP, customer data must be protected. HTTPS, no plain-text passwords, basic input validation.
What almost never belongs in an MVP
Admin panels. You can manage your first 50 customers manually.
Reporting and analytics. You can read the raw database.
Team collaboration features. Start with single-user and add collaboration when users ask for it.
Multiple pricing tiers. One price. One offering. Simplify everything.
Mobile app (if you are starting with web). Web works on mobile. Build a dedicated app when you have validated the product and have budget for it.
Notification systems. Email users manually in the early days.
Integrations with third-party tools. One exception: payment processing if your product charges money. Stripe can be set up in a week and is non-optional if you are charging.
Onboarding flows and tutorials. Talk to early users yourself. You will learn more than any automated onboarding teaches.
The scope creep mechanism that actually works
Scope creep kills more products than bad ideas. The mechanism that prevents it is simple but requires discipline:
Create a document called "Post-Launch Features." Every time someone suggests a feature that is not on the critical path, add it to this document. Do not debate it in the moment. Add it and move on.
This does the following things: it gives every idea a legitimate home (so the person suggesting it does not feel dismissed), it prevents the discussion from happening during the build, and it produces a ready-made backlog for your post-launch development.
The rule: nothing gets added to the active scope without a written explanation of why it belongs in the MVP and an honest discussion of what it will cost in time and money to include.
How to define "done"
An MVP is done when the critical path works end to end, the basic error states are handled, the product is secure and data is persisted, and a real user can complete the core task without asking you for help.
Not when it looks polished. Not when every edge case is handled. Not when the admin panel is built. When the critical path works.
Test this with someone who did not build the product. Give them access and ask them to complete the core task without any guidance from you. If they can, you are done. If they cannot, fix the specific blockers they encountered.
The cost of getting this right versus getting it wrong
Our MVP cost calculator estimates the cost of an MVP based on what you need to build. The range is large: a simple tool with one core user flow built by an offshore team can cost $15,000-$25,000. A product with complex integrations, a custom AI layer, and multiple user roles can cost $60,000-$100,000.
The difference between the high and low end is almost always scope. The founders who spend $100,000 on an MVP have usually included six to ten things that could have waited until after launch.
The founders who launch quickly, learn from real users, and iterate based on actual behaviour rather than hypothetical requirements are the ones who build products that work.
Use the MVP planner to think through your scope before committing budget. Then get an estimate from our team and we will tell you honestly what is MVP and what can wait.