If you are planning your first product build, the term MVP — minimum viable product — is probably the most important concept you will encounter. It is also the most misunderstood. Most founders hear the definition once, nod, then spend six months building a feature-rich product that the market never asked for. This article gives you the practical definition of what is an MVP so you can avoid that trap before it costs you your runway.
The Definition Most Founders Hear (And Why It Leads Them Astray)
The phrase "minimum viable product" was popularised by Eric Ries in The Lean Startup (2011). His original definition: the version of a new product that allows a team to collect the maximum amount of validated learning about customers with the least effort.
That is a precise, useful definition. The problem is how founders interpret the word minimum.
The word 'minimum' is the problem
Most founders read "minimum" as a quality instruction: build the full product but remove the nice-to-have features. So they scope a product with eight core features instead of twenty. They call it an MVP. Then they spend four months building something that still has not tested whether anyone actually wants it.
This interpretation turns the MVP into a compression exercise — a smaller version of the product you imagined — rather than a scientific experiment designed to learn something specific.
Why 'viable' is doing the heavy lifting
"Viable" does not mean polished. It means functional enough for a real user to complete the core job you are asking them to do. Viable is the quality floor, not the ceiling. Once you clear that floor, everything else is optional until you have evidence it matters.
The word that should drive your thinking is not "minimum" — it is "validated." What is the one belief about your business that, if wrong, makes the entire product pointless? Build just enough to test that belief with real people.
What an MVP Actually Is: A Learning Tool, Not a Lite Product
Here is a cleaner way to think about it: an MVP is the smallest thing you can build to test your most important business hypothesis with real users.
That reframe changes everything about how you scope, build, and measure.
The hypothesis at the heart of every MVP
Every product rests on a stack of assumptions. "People will pay for this." "The workflow we designed saves time." "Users will prefer our approach to the incumbent."
Not all of those assumptions carry equal weight. One of them — if wrong — makes the others irrelevant. That is your riskiest assumption. Your MVP exists to test it.
Before you write a single line of code or design a single screen, answer this question in one sentence: What do we believe, and what evidence will confirm or deny it within eight to twelve weeks?
If you cannot write that sentence, you are not ready to scope an MVP. You are ready to do more customer discovery.
What 'viable' means for your target user
"Viable" is always relative to your specific user in your specific context. For a B2B workflow tool, viable might mean the core task can be completed end-to-end without a support call. For a consumer app, it might mean the primary action works reliably on a mobile browser.
Viable is not defined by your feature roadmap. It is defined by whether the user can accomplish the job the product promises. What Is a Product Backlog? Quality, Grooming & Velocity
The build-measure-learn loop in plain English
Ries describes a cycle: build the smallest thing → measure how users actually behave → learn whether your hypothesis holds → repeat with updated assumptions.
The MVP is only the start of that loop, not the destination. Many founders treat the MVP as a milestone to ship and move on from. In reality, it is the beginning of a structured conversation with the market.
MVP vs Prototype vs Proof of Concept: Clearing Up the Confusion
Three terms that regularly get used interchangeably — they are not the same thing. Here is what each one is actually for.
What a prototype is for
A prototype tests a design or interaction concept, usually with internal stakeholders or a small group of target users. It is rarely shippable. Its goal is to answer: does this interface make sense to users? A prototype might be a Figma file, a clickable mockup, or a rough front-end with no real back-end logic.
What a proof of concept proves
A proof of concept (PoC) tests a technical question: can this be built? It is typically internal, used to demonstrate feasibility before committing engineering resources. A PoC might prove that a specific API integration works, or that a particular algorithm can run at acceptable speed.
Where the MVP sits in the sequence
An MVP comes after both. It is a shippable product used with real users to test a business hypothesis. It has enough functionality to produce real behaviour data. The table below summarises the distinction:
| Deliverable | Primary Audience | Primary Question | Shippable? | |---|---|---|---| | Proof of Concept | Internal team | Can this be built? | No | | Prototype | Test users / stakeholders | Does this make sense? | No | | MVP | Real target users | Does this solve a real problem people act on? | Yes |
When to Commission Custom Software vs Extend SaaS
The Over-Building Trap: Why Founders Add Features Before They Should
Over-building is the most common and most expensive mistake in early-stage product development. It happens to smart founders who are genuinely trying to ship a good product. Understanding why it happens is the first step to avoiding it.
Scope creep disguised as product thinking
"Users will definitely want dark mode." "We should add a notification centre at launch." "What if someone wants to export to CSV?"
None of these statements is necessarily wrong. The problem is that they are introduced before there is any evidence the core product works. Scope creep at the MVP stage usually disguises itself as thoughtful product thinking. In reality it is unvalidated feature investment — speculation dressed up as planning.
Every feature added before you have validated your core hypothesis is a bet placed before the cards are on the table.
How technical debt starts at the MVP stage
Over-building does not just waste time on the wrong features. It creates structural problems. When a team rushes to ship ten features instead of three, corners get cut. Database schemas are designed to handle today's scope, not tomorrow's. Shortcuts become permanent. What Is Clean Architecture in Software? Founder's Guide
Our team has worked with founders whose first development partner shipped a feature-heavy MVP on a codebase that required a partial rewrite within six months. The cost of that rewrite — in time, money, and lost momentum — was significantly higher than a well-scoped MVP would have been.
The runway cost of building the wrong thing
Every week spent building a feature no one asked for is a week of engineering cost, a week of delayed market feedback, and a week off your runway. At seed stage, where runway is typically 12–18 months [VERIFY], the compounding cost of over-building is not abstract — it is existential.
The lean principle is not about building cheaply. It is about building only what generates learning, so that every pound or dollar of engineering spend moves you closer to product-market fit. Fixed-Price Software Contract: Is It Right for You?
What a Good MVP Actually Contains (And What It Deliberately Leaves Out)
Scope decisions at the MVP stage come down to a single discipline: every feature must earn its place by directly testing your riskiest assumption. If it does not, it goes on the backlog.
Identifying your riskiest assumption
Write down every assumption your business model depends on. Then rank them by two criteria: how important is this to the business working, and how uncertain are we that it is true?
The assumption that is both critical and uncertain is your riskiest one. That assumption drives your MVP scope.
For example: if your business depends on users completing a multi-step onboarding flow to activate value, and you do not know whether users will complete it, that flow is what you test. Not the reporting dashboard. Not the third-party integrations. The activation flow.
The one-job rule for MVP features
A useful heuristic: your MVP should do one job, end-to-end, reliably. Every feature in scope should be directly necessary for the user to complete that one job. Features that serve a second job belong on the backlog. This is not about building something simple — it is about building something focused.
What to put on the backlog instead
The backlog is not a bin. It is a prioritised list of the things you will build once the core hypothesis is confirmed. When a team member suggests a feature, the response should not be "no" — it should be "yes, and here is where it sits on the backlog."
This reframe keeps morale intact while protecting scope. [INTERNAL LINK: What Is a Product Backlog? Quality, Grooming & Velocity]
Real-World MVP Examples That Worked (And What They Prove)
The best way to make the MVP definition concrete is to look at companies that used the concept correctly. Each of these examples illustrates a different form an MVP can take.
Dropbox: a video before a product
Before Dropbox built their file-syncing product, founder Drew Houston published a three-minute explainer video demonstrating the product that did not yet exist. Overnight, the waitlist grew from 5,000 to 75,000 [VERIFY]. The MVP was not a product — it was a video designed to test one hypothesis: do people want this?
The learning came before any engineering. That is the principle at its most efficient.
Airbnb: three air mattresses before a platform
The Airbnb founders could not afford their San Francisco rent during a design conference. They put up a basic website, photographed their apartment, and rented out three air mattresses. They had no payment platform, no host dashboard, no insurance framework. They tested whether strangers would pay to stay in another stranger's home.
They answered the riskiest assumption — willingness to transact — before building the platform that now hosts millions of listings globally [VERIFY].
Buffer: a landing page before any code
Buffer's founder published a landing page describing the product and a pricing page. Users who clicked "Sign Up" were told the product was not ready yet. The click-through rate from features to pricing validated willingness to pay before a single feature was built [VERIFY].
All three examples test the riskiest assumption first. None of them involve building a feature-complete product with a few things removed. Event Tracking Analytics: A Founder's Guide
How to Know Your MVP Is Ready to Launch
One of the hardest decisions in early-stage product development is knowing when to stop building and start shipping. Here is a practical framework.
The three questions to answer before you ship
- Can a real user complete the core job without assistance? If the answer is no, the product is not yet viable. Keep building.
- Do we have a defined success metric? If you cannot state what "this worked" looks like in measurable terms before you ship, you will not know what the data is telling you after.
- Have we removed everything that is not directly tied to testing the hypothesis? If there is a feature in scope that does not serve the core test, it is slowing you down for no validated reason.
Defining done for an MVP
"Done" for an MVP is not when it feels finished. It is when it is good enough for real users to complete the core job and generate real behaviour data. That data — not user interviews, not internal opinions — is what tells you whether to persevere or pivot.
Common signs you are over-building
- Your launch has been pushed back three or more times for features rather than bugs.
- You are designing flows for user scenarios that have not appeared in any customer conversation.
- The engineering sprint is focused on polish rather than functionality.
- You have more than one "must-have for launch" debate per week.
Our team applies a structured quality gate at each sprint review across engagements — a practice developed across 50+ completed projects — specifically to catch over-building before it compounds. How to Evaluate a Software Development Partner: 9 Criteria
Frequently Asked Questions About MVPs
What is the difference between an MVP and a prototype? A prototype tests a design or interface concept, usually internally or with a small test group. It is rarely shippable. An MVP is a real product shipped to real users to test a specific business hypothesis. The MVP generates behaviour data; the prototype generates design feedback.
How long does it take to build an MVP? Scope determines timeline more than technology does. A well-scoped MVP — focused on testing one core hypothesis — typically takes between 6 and 16 weeks depending on the complexity of the core job. Poorly scoped MVPs, where scope has not been filtered through the riskiest-assumption test, consistently take longer and generate less useful learning. All timelines are indicative and subject to scope confirmation.
What features should I cut from my MVP? Cut anything that does not directly test your riskiest assumption. Ask: if this feature were missing, would users still be able to complete the core job and generate the data we need? If yes, the feature goes on the backlog. This question, applied consistently, is the most reliable scope-control tool available to early-stage founders.
Can an MVP be a no-code product? Yes — if no-code tools allow real users to complete the core job and generate genuine behaviour data, they are a legitimate MVP vehicle. The important caveat is tool limitations: if the constraints of a no-code platform will distort user behaviour (for example, by making the experience significantly slower or more limited than the real product), the learning may be misleading. The question is not whether it is no-code — it is whether it produces valid signal.
How do you validate an MVP? Validation requires defining your success metric before you ship, not after. Real validation means real users completing the core action at a rate that meets or exceeds your pre-defined threshold. Positive qualitative feedback — "I love this idea" — is not validation. Users paying, returning, or completing the activation flow unprompted is validation.
How Decyb Technology LLP Helps Founders Scope and Ship MVPs Without Over-Building
Most of the problems described in this article — burning runway on the wrong features, accumulating technical debt at the MVP stage, shipping a product that is impossible to scale — come from a single root cause: building before the scope has been filtered through a clear hypothesis.
At Decyb Technology LLP, the scoping conversation always starts with outcomes, not features. Before any architecture is discussed or any estimate is produced, the team works to identify the riskiest assumption in the business model and defines what the MVP must prove. That discipline — applied consistently across more than 50 completed projects — is what allows the team to deliver 20% faster than average agency timelines [VERIFY] without cutting corners on quality or architecture.
Starting with outcomes, not features
The brief that Decyb works from is a business-outcome brief: what does success look like in measurable terms, and what is the minimum the product needs to do for a real user to generate that signal? Features are derived from that brief, not the other way around. This is a different conversation from the one most founders have with development partners, where scope is driven by a feature wishlist rather than a hypothesis.
This approach is how projects like FieldFolio — a B2B wholesale marketplace now used by 40,000+ retailers across Australia and New Zealand — were scoped to solve the actual commercial problem first, with complexity added only where evidence warranted it.
What a fixed-price MVP engagement looks like
Decyb offers fixed-price MVP engagements scoped end-to-end, covering custom web application development (React/Next.js and Node.js/Express) and mobile app development for iOS and Android. Fixed pricing is only possible when scope is well-defined — which is why the scoping process is treated as a deliverable in itself, not a formality before the real work begins.
For founders who have been burned by offshore development shops that promise and under-deliver, or by freelance arrangements that collapse mid-project, the consistent ★ 5.0 delivery record across 12+ years of international client engagements is the relevant signal. [INTERNAL LINK: How to Verify a Software Agency's Case Studies]
Getting a technology strategy before you build
If you are in the planning stage — working out what your MVP should contain, which technology stack makes sense, and whether custom software is the right decision at all — Decyb offers a free 24-hour custom technology strategy call with a senior partner. No cost, no obligation. The output is a clear, honest assessment of what to build, what to defer, and what technology decisions will matter most in the six months after launch.
This is the conversation that prevents over-building before the first sprint begins.
Book your free strategy call — get a plan in 24 hours
All project timelines and delivery estimates are indicative and subject to scope confirmation. Third-party service costs (hosting, domains, SaaS tools) are billed separately at cost. Decyb Technology LLP is registered in India; engagements are subject to terms of service available at decyb.com/terms.