Building is cheap now, so what does lean even mean? How to size an MVP, what viable must never sacrifice, and the evidence that proves it worked
The first version of Airbnb did not process payments or show a map, which is the part of MVP folklore everyone repeats, and almost nobody applies. What has changed since that example became canon is that building the real thing is now so cheap that the old reason for cutting scope has quietly disappeared, which turns the question of how lean an MVP should be into a question about evidence rather than budget.
An MVP, or minimum viable product, is the smallest version of your idea that can be put in front of real users and produce real evidence about whether they want it.
The word doing the work is not "minimum" and it is not "product." It is "viable," and viable does not mean functional. It means the version is complete enough that a user's reaction tells you something true.
The test in one line: if the result of your MVP cannot possibly prove you wrong, you have not built an MVP. You have built a demo.
For fifteen years, "how lean should my MVP be" was really asking "how little can I afford to build." That question is close to obsolete, because a small team can now ship a working product in days for a fraction of what it once cost.
The constraint moved, and most teams have not noticed. In an analysis published in July 2026, Marty Cagan of the Silicon Valley Product Group describes what the industry now calls the AI productivity paradox, meaning teams are shipping faster than ever while their outcomes stay flat.
The numbers he cites are stark. Atlassian's 2026 report found that 89 percent of executives say AI has increased the speed of work, while only 6 percent are confident they can point to organisation-wide returns from it.
The same piece quotes AI engineering author Chip Huyen making the point plainly, which is that building got easier while knowing what to build did not. Cagan's conclusion, set out in the AI productivity paradox , is that the constraint was never the cost of building. It is that so many ideas turn out not to be worth building.
Read that against your own MVP plan and the implication is uncomfortable. If building is nearly free, a lean MVP is no longer impressive, and shipping fast is no longer the achievement. The only thing that still counts is whether you learned something you could not have learned any other way.
Cagan draws a distinction that resolves most MVP arguments before they start, which is that building to learn and building to earn are two different activities with two different quality bars.
Most failed MVPs are teams doing the second while telling themselves they are doing the first. They build production infrastructure, admin panels, and billing for an idea nobody has confirmed anyone wants, then describe the result as lean because it shipped in six weeks.
Tip: decide out loud which one you are doing before the first line of code. The two have different definitions of done, and mixing them is the most expensive mistake in early product work.
These five get used interchangeably in conversation and mean genuinely different things in practice.
The pattern worth noticing is that only the MVP tests desire. A proof of concept can succeed while the idea is worthless, and a beta can run flawlessly for a product nobody needs.
There is no universal answer, and anyone selling you one is selling something. Leanness is a dial rather than a setting, and four questions decide where it lands for your product.
The more of these that run high, the less lean your MVP can safely be. A note-taking app can be a single working screen, while a payroll product cannot be stripped much at all without producing a result you cannot trust.
The trap: most consumer software sits at the easy end of all four questions and behaves as though it sits at the hard end. That gap is where months disappear.
Before you size anything, it is worth validating the idea first , because a well-run demand test frequently removes the need to build anything at all.
Tip: step 2 is the one teams skip, and it is the one that makes the whole exercise falsifiable. An MVP with no failure condition is a launch wearing a lab coat.
Every one of these has launched a real company, and none required a finished product.
Warning: the concierge and Wizard of Oz approaches only work if you can deliver the promised outcome. Simulating a result you cannot actually produce is not a test, it is a broken promise.
Lean is a licence to cut scope. It is not a licence to cut the things that make a result trustworthy, and three lines should never move.
Honesty. Users must know what they are getting. A test that works only because people were misled has taught you nothing about the real product.
Safety of their data. If you collect it, protect it properly. There is no lean version of losing someone's information.
Doing the one thing well. Whatever your MVP promises, that single promise must be kept properly. A user who forgives a missing feature will not forgive the feature that exists and fails.
The most common failure at this stage is treating enthusiasm as evidence. People are generous with encouragement and stingy with behaviour, and only one of those is data.
Signals that count:
Signals that do not count:
If your MVP produced only the second list, the honest reading is that you have no answer yet, which is a different situation from having a negative one.
1. Confusing minimum with unfinished. Minimum means fewer things. Unfinished means the things that are there do not work, which produces feedback about your execution rather than your idea.
2. Testing a risk you were never worried about. Teams instinctively test whether something can be built, because that feels productive, while the actual risk was almost always whether anyone wants it.
3. Having no hypothesis you could fail. Without a number written down in advance, any result gets read as encouraging, and the MVP becomes an expensive way to confirm what you already believed.
4. Building for the wrong buyer. The evidence you need differs sharply depending on who is buying, which is one reason the B2B and B2C differences matter well before you write a roadmap.
Here is the awkward economics of an MVP. It is the one build you should fully expect to throw away, which makes it close to the worst possible thing to spend scarce cash on, and yet it is usually the first thing founders pay for.
That tension is where BEXHUB fits. A designer for a week, an engineer for a sprint, or a researcher to run ten proper user interviews can come to you through a collaboration settled in BEX, which means the version you are likely to discard costs you expertise rather than runway.
It also changes who is available to you. The specialist who would decline a small, short, uncertain piece of paid work will often take on a collaboration that returns something they actually want, and short uncertain work is exactly what an MVP is made of. Members can also work in money on any listing, with zero commission either way, so the choice stays yours per project.