A minimum viable product is the smallest version of something you can build that lets you learn the most from real users with the least effort. It exists to answer one question fast: should this be built at all? Most teams skip that question. They spend months perfecting a product nobody has tried, then discover the market wanted something else.
That gap is the expensive one. We have learned that the hard part of a 0-to-1 build is rarely the engineering. It is the discipline to build less than you are capable of building, ship it sooner than feels comfortable, and let real use tell you what to do next. This article sets out what an MVP is, corrects the most common misreading of the term, and walks through a one-hour exercise for deciding what belongs in version one.
What an MVP is, and the question it answers
The term comes from Eric Ries and the lean startup. The method runs on a build-measure-learn feedback loop, and the first step, in Ries's words, is "developing a minimum viable product (MVP) to begin the process of learning as quickly as possible." The point is the loop, not the product. An MVP is the entry ticket to learning, not a smaller version of the finished thing.
So a minimum viable product is the least you can build to test your riskiest assumption with real users. It is deliberately incomplete. It is honest about what it does and does not do. And it is shipped, because a prototype that never reaches a customer teaches you nothing.
The mental shift Ries describes is the whole game. The question moves from "Can this product be built?" to "Should this product be built?" The first is an engineering question, and the answer is almost always yes. The second is a business question, and you can only answer it with evidence from people who are not you.
An MVP is not a small version of the final product
The most common misreading of the term goes like this: take the full product you have in mind, keep every feature, and build a rougher version of all of it. Version one of the real thing, corners sanded off.
That model fails on both ends. It keeps too much, because every feature you were going to build is still on the list, just built worse. And it teaches too little, because nothing in it is designed to test a specific assumption. You end up with a product that does many things poorly and answers no question cleanly. The lean startup warns against exactly this habit, where teams "spend months, sometimes years, perfecting that product without ever showing the product, even in a very rudimentary form, to the prospective customer." A product built in private is a long, expensive bet placed before you have seen a single hand of cards.
The correct model: an MVP is an experiment with a product attached. It is not a proof of concept that lives on your laptop, because it must reach real users. It is not a rough draft of every feature you eventually want, because it deliberately contains almost none of them. It is the cheapest honest test of the one belief that sinks the idea if that belief turns out to be wrong. Judge it by what it taught you, not by how much it shipped.
Most of what gets built is barely used
Over-engineering is solving problems you do not have yet. It is the dashboard with twelve filters when users need two. The flexible, configurable system built for a scale you have not reached. The edge case handled beautifully before you know the common case works.
It is also the most expensive habit in software, and the data is blunt about it. Pendo's 2024 software benchmarks found that of every 100 features a product ships, only about six drive 80% of the usage. The rest are rarely or never touched. Most of the work, gone, because it answered questions nobody was asking.
The outcomes follow. The Standish Group's long-running CHAOS research has consistently found only about a third of projects succeed outright, with the rest challenged (late, over budget, or missing required features) or cancelled. Building more does not move you up that table. It moves you down it, because every extra feature is more to specify, more to test, more to maintain, and more to get wrong.
The costs rarely show up as a single line on an invoice. They arrive as time. Every feature you add before it is needed is a feature you now have to carry. It slows the next release. It complicates the codebase. It makes the product harder to explain to the customer and harder to change when the customer finally tells you what they actually wanted. This is the same waste we examine in our piece on discovery and audit: the cost of a wrong decision made early, multiplied by everything built on top of it.
The edge-case trap: certain effort against uncertain problems
There is a particular version of this that catches careful, conscientious builders: trying to handle every case before launch. What if a user uploads a 2GB file? What if two people edit the same record in the same second? These are real questions. For a first build, they are also mostly hypothetical, and you are spending certain effort now to defend against uncertain problems later, before you know whether anyone will use the feature the edge case belongs to.
The discipline is to handle the common path well and let the rare path fail loudly and safely. A clear error message for the 2GB upload is cheap. A full streaming-upload architecture, built before a single user has tried to upload anything, is not. You can add the architecture the week a real user hits the limit. You cannot get back the month you spent building it for nobody. Systems thinking makes the same point from the other direction: optimise one part in isolation, such as making the upload bulletproof, and you can starve the parts that actually decide whether the product is useful.
"AI can do it" is not a reason to add it
There is a newer version of over-engineering, and it is the most seductive one yet. AI has made more things possible and cheaper to build. A feature that once took a week of effort to justify can now be generated in an afternoon. So the reasoning slips: it is easy now, so why not add it?
Because easy to build is not the same as worth building. The question an MVP forces, "should this exist?", does not change because the cost of building dropped. If anything, cheap construction makes the discipline more important, because the friction that used to stop you from over-building is gone.
The evidence that AI does not rewrite sound engineering is sharper than most people expect. A randomised controlled trial by METR had 16 experienced open-source developers, averaging five years on their own repositories, complete 246 real tasks. With AI tools allowed, they were 19% slower, not faster. The same developers had expected a 24% speedup, and outside experts had forecast gains of 38 to 39%. The gap between how productive AI felt and how productive it actually was ran to more than 40 points.
The pattern holds at the system level. The 2024 DORA report, drawing on roughly 3,000 respondents, found that a 25% increase in AI adoption was associated with an estimated 7.2% decrease in delivery stability and an estimated 1.5% decrease in throughput, even though 75% of respondents reported feeling more productive. More capability, applied without discipline, made delivery worse. The lesson for a 0-to-1 build is plain. AI is a faster way to build the thing. It is not a reason to build more of it. We make the related case in what AI cannot do: the judgement about what should exist stays human.
The cut-list: scope version one in an hour
The antidote to over-building is an hour of sorting, done before any build starts. Get the feature list out of your head and onto a page, then force every item through the same three-way decision.
- 1.List every feature you believe the product needs. Do not filter yet. Long is fine; honest is the point.
- 2.Write the riskiest assumption at the top of the page: the single belief that makes the product pointless if it is wrong. "Tradies will pay for automated quoting" is testable. "People like saving time" is not.
- 3.Sort every feature into three columns. Build now: version one cannot test the assumption without it. Fake it: deliver the outcome manually behind the scenes, such as sending the "automated" email yourself. Cut: revisit only if real users ask for it.
- 4.Challenge the build-now column once more. For each item, ask whether a person could do it by hand for the first 20 customers. If yes, move it to fake it.
- 5.Set the learning goal in numbers before you build: the result from real users that would convince you to continue, and the result that would convince you to stop.
- 6.Put a ship date on what remains. A version one without a date is a roadmap, not an MVP.
The value of the exercise sits in the two right-hand columns. Fake it is how you learn whether people want the outcome before you pay to automate it. Cut is where the features nobody will use go before they cost anything. If Pendo's numbers hold for your product, most of your original list belongs there.
What earns a place in version one
The same candidates come up in almost every scoping session, so here are our standing verdicts.
| Candidate feature | Verdict for version one |
|---|---|
| The workflow that tests the riskiest assumption | Build it, and build it well |
| Login and user accounts | Defer if a shared link or spreadsheet can stand in |
| Admin dashboard | Fake it; read the data directly for now |
| Online payments | Manual invoicing first, unless payment is the assumption |
| Integrations with every tool you use | Build the one that removes daily manual work, cut the rest |
| Edge case handling | A clear error message now, architecture when a user hits it |
The rule underneath the table: a feature earns a place in version one only if the test fails without it. Everything else waits for evidence.
Ship, measure, then decide
The way out of over-engineering is not caution. It is sequence. You ship the smallest honest version, you measure what real people do with it, and only then do you decide what to build next. That order is the entire discipline, and most teams reverse it.
Measuring matters as much as shipping. An MVP that goes live but is never observed is just a small product launched on a hunch. The loop only closes when you watch real behaviour: what people use, what they ignore, where they get stuck, what they ask for that you did not build. That signal tells you which of your remaining ideas is the unused half and which is the part that was sorely missed.
This is also how you avoid the opposite failure, underbuilding. Over-building and under-building are two halves of the same waste, and the fix for both is the same. Build the right small thing, learn, then build the next right small thing. Scope is not a one-time decision made at the start. It is a series of small decisions made with evidence you did not have before.
The Australian picture
This is not an abstract concern for local businesses. Capability is no longer the constraint. Getting value from it is. Deloitte Access Economics surveyed more than 1,000 Australian small and medium businesses and found that two-thirds are already using AI, while only 5% are "fully enabled" to realise its benefits. The report estimates that if just one in ten of these businesses advanced one rung on the AI adoption ladder, $44 billion could be added to GDP each year.
Read that gap carefully. The tools are in hand. The value is not. The distance between adopting a capability and shipping something that genuinely does the job is exactly where MVP discipline earns its keep. The businesses that win are not the ones that build the most. They are the ones that build the right small thing, see whether it works, and move. We look at this adoption gap in more detail in our piece on AI adoption in Australian small business.
The Enki Approach
We build less on purpose. Every engagement starts by finding the one assumption that decides whether the idea works, then scoping the smallest build that can test it honestly. We resist the configurable, the flexible, and the future-proof until a real user gives us a reason to add it.
That discipline is unfashionable. It is also why our custom builds and automations reach value faster and cost less to change. We would rather ship something small that teaches us the truth this month than something polished that confirms our assumptions next year. If you are weighing up mvp software development for a 0-to-1 product, the right first question is never how much we can build. It is how little we need to build to learn whether we should.