AI made minimum cheaper, but context still shapes what viable means

MVP, when it truly works, feels less like a triumph and more like a quiet realignment. It is about whether the product is doing something genuinely useful, early enough to let the learning shape what comes next. But what counts as “early enough”, and how little you can get away with building depends entirely on context.

A teaching assistant built for the live classroom moment, designed to support the trainer as they taught. The longer vision stretched further, from the trainer’s experience to the learner’s, and eventually into how learning itself gets measured. But before any of that vision could be chased, there were two grounded questions standing in the way: would this assistant actually be helpful, and would it aid the learning process rather than disrupt it?

The stakes were real. If the assistant disrupted the flow of how a trainer taught, the learning experience suffered. And if trainers rejected it early, every subsequent release would be walking into a room that had already made up its mind. Adoption is hard to win back once it is lost. And the stakes went beyond adoption because a significant investment was also needed in creating supporting content around the product vision. The first release was small by design and complete by intention. It addressed one slice of a live teaching experience clearly enough that a trainer could use it, form a real view, and tell the team something meaningful. Not the full vision. Not even close. But enough to put something genuine in front of the people who mattered most.

The feedback that came back was mixed, and that was not a disappointment. Some things resonated immediately. Others did not land the way anyone expected, and a few assumptions the team had held with confidence turned out to be wrong. But none of that was discouraging because it was all directional. The team tweaked, refined, and released again. Then again. Each cycle brought the product closer to what trainers actually needed rather than what the team had imagined they needed.

It was a win. Not a loud one, but a real one. Looking back, what made it work was not the technology, the roadmap, or even the idea. It was the clarity of what viable meant for the trainer, and how small the release could be while still answering the core question. The order of the questions mattered: What do we need to learn? What is the least we need to build to test that learning? Everything else followed from there.

That was close to a decade ago. The learning loop worked, but it was slow and expensive. Building even that first small slice took significant time and engineering commitment before a single trainer could react to it.

Recently, while exploring what AI can actually do end to end, we built a functional prototype for a different problem in weeks. Not just the code but the MVP proposal, user journeys, stories, and a development plan across two parallel tracks all came together in that same window. Connected to a data source, generating metrics, usable enough to put in front of someone and get a genuine reaction. Not a mockup. A working thing.

Looking back at the teaching assistant with that experience in hand, the same validation that took months could now reach a trainer in weeks too. An AI powered prototype, functional enough to feel real paired with an LLM pulling from real curriculum data, generating content for the product, is buildable now at a fraction of the original cost and time. The question of what to validate would not change. The thinking that shaped that first slice would still have mattered. But the cost of getting to the signal would be unrecognisable.

But what counts as minimum is rarely the same twice. In the teaching assistant product, a single slice of the experience was enough to generate real signal. The context was focused and contained, and that was enough. Even then, getting to that first signal required a rough prototype, something more than clickable screens but far from complete, shown to teachers across a handful of selected partner schools. That alone took months.

AI is changing that. A prototype that once took months to be real enough for genuine user reaction can now be assembled in days, functional, connected to real data flows, good enough to put in front of someone and get a meaningful response. The cost of reaching minimum is lower than it has ever been. The loop between build, learn, and iterate is compressing. And that is a good thing. AI compresses the build. It can generate functional UI from a description, create data flows from an API spec, simulate interactions before real users exist. What it does not compress is the judgement of which slice to test, who to put it in front of, what signal you look for, and when to stop iterating and commit. That judgement is where context takes over.

In some contexts that bar remains high regardless of what AI makes possible. Sometimes the market you are entering, the competition you are facing, and the habit you are trying to displace demand more before genuine learning becomes possible. AI can help you get there faster. It cannot tell you where “there” is. That is still on you.

I once worked on a product with a large vision and a competitive market. An established player already owned the space with deep distribution and genuine user trust. They had already made basic transactions feel effortless. That was the floor we had to clear before we could even be considered. For someone to choose us, we had to offer something worth disrupting behaviour they had already automated.

That context changed everything about what minimum viable meant.
The core was the differentiator. But what people genuinely cared about was not the core feature alone. It was access to curated experiences and the feeling of being part of an elite tier by providing something selective like priority bookings, personalised offers, visible tier system. That required more than one feature to deliver convincingly. Without the features that made that promise real in everyday moments, the core remained a capability rather than a proposition.

So minimum, in this context, was not small. It was a carefully considered set of features that together cleared the bar of why would someone switch. Some features went into parallel streams correctly as product extensions not foundations. But what remained was still a substantial first release by most MVP standards. And it needed to be.

Looking back AI could have accelerated the build of each feature in that set. But it could not have told us which features belonged in it. That was a market judgement, a competitive read, a bet on what would make someone disrupt a habit they had already automated. What would have mattered would be the business context we brought to the table and the lens through which we evaluated every option. AI would have worked here as a sparring partner for testing the bets, surfacing what we might have missed, stress-testing assumptions against patterns it has seen. But the bets themselves are yours. The context you feed it determines the quality of what comes back. Use it to validate your thinking, not to replace it.

The real test is not whether the MVP is small, but whether it is small enough to generate learning worth acting on. That answer looked very different here than it did for the teaching assistant. Both were right.

If anything, the clarity of thinking required upfront matters more now, because the temptation to build and iterate without that clarity will be stronger when building feels cheap. And cheap is worth questioning too. The cost curve is lower, but it is not flat. When building was expensive, the cost enforced the thinking. You couldn’t afford to build the wrong thing, so you spent time figuring out what the right thing was. Now you have to enforce that discipline yourself.

The danger is not that AI makes building easy. It is that easy building makes it tempting to skip the thinking that tells you what to build. Ship fast, learn later might sound like a strategy. But if you never asked the right question before pressing go, the cycle happens but without generating signal. You might iterate on the wrong thing faster.

This is where the cost of being wrong has shifted. Building is cheaper. But building the wrong thing and discovering it three iterations later still costs time, focus, tokens for AI and most importantly credibility with the users you put it in front of. AI compresses the build. It does not compress the consequences of building without clarity.

Minimum is always a consequence of viable. It follows from what viable demands. And viable is never universal. It shifts depending on your users, your market, and what genuine engagement looks like in your context. So when you next draw the boundary of your MVP, ask yourself: are you starting from what viable demands, or are you working backwards from a vision that is already fully formed?

MVP: Minimum Is Not a Number was originally published in Technogise on Medium, where people are continuing the conversation by highlighting and responding to this story.