Minimum Viable Product Was Never About the Code. AI Proved It

Years ago at Stackify, the developer-tools company I started after VinSolutions, we spent $10,000 sponsoring a developer conference to launch our first product. The idea was secure access to production servers. We built it, we paid for the big booth, and we waited.

We got zero new customers.

The product was fine. The code worked. Nobody wanted the thing it did. I had spent months and real money building an answer to a question almost no one was asking, and the conference was where I finally found that out.

That experience is the whole point of a minimum viable product, and it’s the part most people still get wrong. A minimum viable product was never about writing less code or shipping a cheaper version one. It was always about learning whether anyone wants what you’re about to build before you bet your time on it.

I’m Matt Watson), CEO of Full Scale, a software development company. I’ve started four software companies and built an MVP for every one of them, going back to when I was a 22-year-old college dropout writing software for car dealerships. That became VinSolutions, which we bootstrapped to $35 million in annual recurring revenue with no outside money and sold for $147 million. I’ve also watched the MVP get easier to build every year, and I run a company where I see what founders show up with.

AI changed how fast you can build. It barely touched the part that was always hard.

What a minimum viable product actually is

A minimum viable product (MVP) is the smallest version of a product that lets you learn whether your idea is worth pursuing. Not the cheapest build, but the fastest path to a real answer from real users.

The term traces to Frank Robinson, who coined it around 2001, and it spread through Steve Blank and Eric Ries, whose book popularized the build-measure-learn loop. The loop is simple. You build the least you can, you put it in front of users, you measure what they actually do, and you learn enough to decide your next move.

The word that does the work in that phrase is viable, not minimum.

Viable means it delivers enough real value that someone will use it and tell you the truth about it. The form barely matters. A landing page that explains your idea and asks people to sign up can be a viable MVP. So can a concierge version where you deliver the service by hand before you automate anything, or a single working feature instead of the whole roadmap. Each one is just a different instrument for measuring the same thing: does anyone actually want this? A polished app nobody needs fails that test no matter how much code went into it.

An AI prototype is not an MVP

This distinction matters more now than it ever has, because AI made it trivial to produce something that looks like a product.

A prototype shows that something can work. A proof of concept answers whether a thing is even technically possible. An MVP puts real value in front of real customers to find out if they want it. Those are different jobs, and a weekend of prompting an AI coding tool gets you the first one, not the last.

I’m not knocking the tools. They’re genuinely good at this. As I’ve said before, you can slap a bunch of things together with AI and build your little shack, but it might catch on fire. Fast output is not the same as production software, and a demo that impresses you in a meeting is not the same as a product a customer relies on. If you want a real look at what the current AI prototyping tools can and can’t do, we covered them in detail in our guide to AI prototyping tools.

The danger is mistaking the prototype for the validation. The prototype proves you can build it. It tells you nothing about whether you should. And once you have proven you should, you still don’t need to build it to scale on day one.

What AI actually changed

Building got cheap and fast, and the numbers back that up.

GitHub’s own controlled study found developers finished a coding task about 55% faster with Copilot. JetBrains found that roughly 85% of developers were regularly using AI tools by 2025. A founder today can put a working demo in front of a prospect that, a few years ago, would have taken three engineers and a designer working for months. When you’re early and your time is the only resource you have, that’s a real advantage.

So the floor went up. Anyone can build now.

The floor went up, but the hard part barely moved. Knowing what to build and proving someone wants it is still the durable, valuable work, and AI mostly nibbles at the edges of it. It can draft your outreach and spin up a fake landing page to test demand, but it can’t decide who to talk to, hear the thing a customer won’t say out loud, or make the call to kill an idea. That judgment is the actual job, and the go-to-market work around it is the real secret sauce. Writing code was always the easy part next to building a sales motion that works, and AI just made the easy part easier.

You’ll see a lot of headlines right now claiming AI ships MVPs in days and cuts costs by 85%. Treat those as claims about the building, because that’s all they measure. They aren’t wrong about speed. They’re measuring the part that was never the bottleneck.

Most MVPs get released, not validated

Here’s the uncomfortable truth I’ve lived more than once. Most MVPs don’t get validated. They get released, then ignored, then buried in a backlog while the team wonders what to build next.

CB Insights studied why startups fail and found the top reason, ahead of running out of money, was no market need. About 42% died because they built something the market didn’t want. That is a validation failure, not an engineering failure.

My Stackify conference launch was exactly that. So was the trap I fell into later at the same company: endless ideas, a solid roadmap, constant releases, and a product that still didn’t resonate because we weren’t asking whether the work mattered to the customer.

Even at VinSolutions, where things went well, the feedback loop decayed as we grew. Early on I could talk to a dealer in the morning and ship a fix that afternoon. By the time we scaled, customer feedback reached me through a support person, then another layer, then another, until I had four people between me and the customer and only really talked to users at trade shows. We kept shipping the whole time. We had just stopped hearing the truth.

The AI last mile

I have a lot of friends who are builders, and right now they’re addicted to AI coding tools. They build and build and build. What they almost never do is the last mile: getting on the phone, talking to customers, and selling.

I call it the AI last mile, and it’s where most of these projects quietly die.

Builders are allergic to selling. That’s not an insult, it’s just how a lot of us are wired. Writing code feels like progress, and a sales call feels like rejection waiting to happen. AI removed the one excuse that used to protect us, which was that building was slow and expensive. Now building is fast and cheap, so the only mile left is the one builders skip.

Vibe coding all weekend and never selling anything is a hobby, not a business.

That’s the line I keep coming back to. Building things doesn’t make you an entrepreneur; selling does. The founder is usually the one with the product vision and the industry relationships, the one who should be closing the first ten customers, and that’s exactly the person who can’t afford to spend the year heads-down in an AI editor.

I’ve watched the difference play out inside my own venture studio at Full Scale. We’ve built products where people gave us feedback that sounded great, and then when it came time to actually use the thing, they had a million reasons to keep using something else. We’ve also built products where we talked to people first, and they called us back begging to know when it would be ready. It was the same team using the same tools both times. The only difference was whether we’d found real demand before we built, and you only find that by talking to a lot of people.

Years before that, I ran a company called At Capacity that built websites and a Google Ads management platform for home-services businesses like plumbers, HVAC companies, and electricians. From day one, we spent most of our energy talking to customers, validating the product, and figuring out how to find the next customer as fast as possible. The building was never the question we worried about. Finding the market was.

One of our product managers at Full Scale, Jerell Velarde, has a name for the healthy version of this. He calls it prompt prototyping: using AI to mock up a flow and validate an idea in a single day, with no sprints and no engineering backlog, specifically to kill bad ideas before they reach the roadmap. The goal isn’t to ship the prototype. It’s to answer one question fast. Does this idea matter?

When the prototype works just long enough to break

There’s a specific failure I see constantly, and it’s almost a victim of its own success.

The AI-built prototype works well enough to land a customer. Then that customer starts using it for real. They ask for things, they find bugs, they hit edge cases nobody anticipated. Suddenly the founder is the only person on earth who understands how the application works, because they built it with an AI tool during nights and weekends, and now they’re stuck maintaining it instead of selling.

That’s the handoff moment, and it’s where you need real engineers.

The good engineers are more valuable now, not less. They know exactly where AI helps, where it hallucinates, and where it quietly produces spaghetti that will haunt you in production. This is also why the team you build after validation looks different than it used to. You need fewer pure coders and more people who think about the product, and you need people who can take a scrappy validated idea and turn it into something that holds up. Putting senior engineers onto your product, the kind who know where AI fits and where it doesn’t, is most of what we do.

How to build a minimum viable product for validation, not version one

If you take one thing from this, let it be the order of operations.

Start with the customer, not the code. Talk to enough people that you can describe their problem better than they can. Then build only the smallest thing that answers your next real question, which is usually “will anyone actually use or pay for this,” not “can we make it work.” Put it in front of real users and watch what they do instead of what they say.

That last part is where most teams fool themselves, so be honest about what counts as a yes. People telling you it “sounds great” is not validation. People paying, switching off the tool they use today, coming back a second week, or calling to ask when it ships is validation. The two Full Scale Ventures products I mentioned are the whole test in miniature: polite feedback meant no, and people chasing us to use it meant yes. If the signal is real, keep going. If it isn’t, kill the idea before it eats another quarter.

The hardest discipline is cutting scope, and AI makes that discipline harder, because it lowers the cost of adding just one more feature. If you want the deeper playbook on keeping an MVP small enough to learn from, we wrote a whole piece on why cutting scope beats process.

The old MVP question was “can we build it.” The new one, now that almost anyone can build it, is “should we, and does anyone want it.” That’s the question that was always underneath the MVP, and the Product Driven philosophy I write about is mostly about staying honest with it.

If you’ve validated an idea and you’re staring at a prototype that’s starting to crack under real users, that’s exactly the point where a real engineering team earns its keep. That’s the conversation Full Scale is built for. We can put senior engineers on your product who know where AI fits and where it doesn’t.