Short answer: no, the MVP idea still works. But with AI, the first version a team builds in days or weeks is often more than a minimum: it's already a product, just an untested one. Build to learn what to build next.
Not long ago, a founder came to us with a good part of their product already built. Driven by a deep understanding of the problem, they'd used AI to bring the idea to life quickly, vibe coding their way through a long list of features. We helped improve and consolidate what was there, but the interesting part was something else. The product was anything but minimal: it had far more functionality than a first version needs, yet it had been shaped almost entirely by one point of view, the founder's own.
An early beta was supposed to widen that view, but adoption was modest. So the product rested on an assumption almost every founder starts with: that the problems they know firsthand are shared by enough other people. It may well be true. It simply hadn't been tested yet.
As of today, the product is live in production, with 15 user-facing features spanning 92 user stories, and the focus has shifted to learning from real usage. In our estimate, based on which features the core idea actually depended on, about half of those features would have been enough to start validating the idea, and the rest could have followed once there was evidence. The project itself went well, and it still shows something that's easy to forget when building gets fast: finishing a product tells you it can be built, and nothing about whether anyone needs it.
What was the MVP originally meant to be?
The original idea behind the MVP still holds: spend the least effort possible to learn the most about whether you're on the right track. In the lean startup approach that Steve Blank helped pioneer, an MVP was whatever artifact gave you the most learning at a given moment. That could be a landing page to test a go-to-market idea or a price list to test revenue. It didn't have to be software at all.
Over time, the meaning drifted. In many teams the MVP became a polished first version, ready to launch, and success started to be measured in features delivered instead of things learned. Finishing it began to feel like a validation milestone, when all it really proves is that the team was able to build it. The concept held up; what changed was how teams used it.
How has AI changed the MVP?
AI left the purpose of an MVP intact and changed what one looks like: a small team, or even a single founder, can now produce a working product with a long list of features in days or weeks. In the example above, starting from the founder’s version, we had a product ready for beta testing within a few weeks, and a production-ready one a few weeks later, a pace that would have taken several months not long ago. What used to signal effort, skill, and commitment is now cheap to produce. That cost also worked as a filter, because you had to be fairly convinced before investing months in something, and AI has removed that natural pause.
Cheap to produce doesn’t mean easy to deliver well, as our VP of Engineering, Matias Mansilla, argues in Why software still takes time in the age of AI, and our CTO, Anthony Figueroa, looks at what else this shift breaks in The assumptions behind software engineering are expiring. But it does change what the first version tells you.
Steve Blank reflected on exactly this in September 2026, writing about how AI changed his Lean LaunchPad class at Stanford. As he describes it, an MVP used to serve two purposes: it showed that something real could be built and reflected what had been learned about customers' problems, and it was a way to test the whole business model as well as the product. With AI producing working products on day one, that evidence stops being reliable: having something that works no longer tells you whether customer discovery happened, hypotheses were tested, or product/market fit was found. His response was to call these day-one products Initial Untested Products, or IUPs.
What is an Initial Untested Product (IUP)?
An Initial Untested Product (IUP) is a working first version, often built quickly with AI, that hasn't yet been tested with real users.
The name does something useful. Initial marks it as a starting point, and Untested is the honest part: however much has been built, the hypotheses behind it haven't been checked against real users yet. You'll see other names for the same idea, and many people will keep calling it an MVP. Some will say it's just a rebrand of an old problem, which is fair. What matters is the idea: a product can be impressive, well built, and live in production, and still be an IUP.
What I find valuable in Blank's framing is that it doesn't blame the tools. Building faster is fine. The risk is putting all the energy into building more without validating, and ending up with a great product, full of features, that nobody has validated.
Does a working product prove product/market fit?
No. A working product proves that it can be built, and nothing more. Every product has to answer three questions, and building answers only the first:
- Can we build it? Building answers this one.
- Do people want it? Only real users can tell you.
- Can it sustain a business? Only evidence over time can show it.
In the example above, only the first question had an answer. Engineering has traditionally owned it, and AI has made it easier to answer than ever. That's why the other two deserve more attention now.
How do you build to learn, not just to ship?
Building to learn means organizing the work around the questions you most need answered. Building to ship organizes it around a list of features, the way most delivery practices were designed. Bruno Alfaro gets into how those practices are changing in The future of Agile in AI-native software development. The idea is not new: it echoes the build-measure-learn loop from lean startup. What changes is that when building takes days or weeks, the loop is limited by what you choose to learn, not by how fast you can ship. The difference shows up in how success is defined:
In short, building to ship aims to deliver the agreed scope and measures success in features delivered, so the work ends at launch. Building to learn aims to reduce the biggest uncertainty and measures success in evidence gathered, so launch is where the learning starts.
A few habits help, and none of them require slowing down.
- Write down your hypotheses before you build. Who has the problem, why would they switch, and would they pay? If you can't state them, you're building on assumptions you haven't noticed.
- Put the product in front of people who aren't you. The founder's own problem is a good starting point, but it's a sample of one.
- Measure what users do. What users say they'll do and what they actually do are different things. Analytics gives you evidence of real usage.
- Know why each feature exists. Some test a hypothesis. Others are simply necessary, like security or letting users delete their account. Build the necessary ones simply, and question any feature that's neither. AI makes it easy to add features faster than you can ask why.
- Decide in advance what would change your mind. Define what evidence would make you continue, iterate, or rethink, so launch becomes the point where learning starts.
How does Rootstrap approach building to learn?
At Rootstrap, our role goes beyond turning a scope into working software. We try to build with learning in mind: asking which hypothesis each feature helps test, pushing to involve real users early, and instrumenting what we ship. When a client arrives with an idea, or a product already built, part of our job is to help them see what's proven, what's still an assumption, and what to do about it.
That’s what we aimed for in the project I described: build on what the founder had already made and put analytics in place, so decisions about what to build next rest on how people actually use the product. It’s the kind of partnership we want to offer, one that measures success not only by code quality and delivery speed, but also by the value the product creates for the business.
What should you ask after the first version ships?
A first version gives you the chance to start learning whether you have a viable product.
So the next time a first version is done, try changing the question. Instead of asking "What should we build next?", start by asking "What do we still need to validate?"
If you have a first version and want an outside read on what it proves so far, talk to our team.
