What does a minimum viable product need to prove when AI makes building cheap?

When building is cheap, a minimum viable product has to prove more than whether people want the thing. It has to show the business is holding onto something a copy of the product cannot take.

Eric Ries defined the MVP in 2011 as the smallest test that produces the most learning about customers for the least effort. The argument I hear in practice runs the other way. People want something to point to when they walk a potential customer through the idea, so they build a rough version first, ahead of learning whether anyone wants it. Founders set up a landing page too, because it was cheap to stand up and gave whatever marketing they were running somewhere to send people. But they built the thing on hope regardless. Building cost real money then, so being wrong was expensive. AI removed the cost, and being wrong got cheap. A founder can now ship the finished product as the test itself. When the idea is wrong, they built something no one wanted. When it is right, shipping it proves less than it once did, because the product is no longer the costly, scarce thing that used to make building one mean something. The same tools that compressed the build let a competitor copy it just as fast, and the limit on copying is now token budget and model quality, not the time an engineer once needed.

The MVP Is a Test of the Business

Ries filled his own book with MVPs that were not products. Drew Houston proved demand for Dropbox with a three minute video of software that did not fully exist yet, and the beta waiting list jumped from 5,000 to 75,000 people. Other founders ran a concierge version, delivering the service by hand to a few customers before writing any code to automate it. These were not full products, and in some cases not even partial ones. A three minute video of software that barely existed, or a service run by hand with no code behind it, still tested the assumption the business rested on. The product comes after the assumption survives, and the assumption is not proven until customers adopt the product.

So the argument going around now, that an MVP should be a landing page and a payment button rather than an app, is mostly Ries restated. He said it first, with the video and the concierge service. Calling it a correction gets the history wrong. Ries's landing page was one mechanic for a deeper discipline, holding off on building until the idea has earned the effort. That discipline is harder to keep now, when the tools make building the easy path and the assistant in the corner keeps asking what it can build for you.

What AI Made Cheap, and What It Did Not

The loop Ries described, build a little, measure what real people do, then decide, had two separate costs bundled together. One was proving people want the thing, through a landing page, a video, or a waiting list. That was already close to free in 2011. The other was building the working product. That was the expensive one, and it is the one AI collapsed.

Confusing the two is where the argument that an MVP is free goes wrong. Proving demand was rarely the expensive part, so "AI made the MVP free" points at a cost that was already low. The cost that dropped is building the real product. A finished app was scarce, so making one was evidence someone believed in it. Copying took an engineering team. And putting customers behind untested software took enough commitment that few did it by accident. Take the expense away and you are left with three risks that argument skips. A working app no longer proves demand, a fast build exposes real users the moment it handles their data or a payment, and the product itself can be copied on a competitor's timeline.

A Working App Stopped Being Evidence

A working app used to take months and real money to build. That cost showed a founder believed in the idea, and an investor could see it too. Early users could not get the thing anywhere else. Signups for a rough version meant something because the rough version was scarce.

That scarcity is gone. When the same build now takes a fraction of the time, the app itself tells an investor or its own founder very little. The proof has to come from what people do with it. Did anyone pay? Did the people who signed up return a second week without a prompt? Is their own data going in and staying in? Interest was a weak answer to the demand question even before this, and AI made it weaker, because interest in a category can now be satisfied by a dozen quick builds that look equally finished from the outside, whatever is missing underneath.

A signup measured desire when apps were expensive to make. Now it measures curiosity.

When Speed Exposes the User

The working app also carries a cost the landing page does not. A model can generate an application that looks finished with the guardrails missing. Endpoints that should check who is allowed to see a record skip the check. One account can read another account's data, or a dependency the model pulled in carries a known hole. These stay hidden in a demo, which by design runs the happy path, the one flow built to work. In practice you demo with data you have already tried. The problems surface when real data leaves that path, or when a malicious user gets in.

For a throwaway experiment holding no real data, that is a fair trade. For something holding customer records or taking a payment, the version that shipped fast has taken on real users and real exposure at the same time. Building got cheaper. A breach costs the same as it did before, paid by your users in exposed data and by you in lost trust. Reading a generated system well enough to tell a sound build from a plausible one is its own discipline, and it sits with the deployment decisions covered in the related insights below. If the assumption you are testing is demand, a working app is the most exposed way to test it, and it no longer convinces on its own. The evidence that counts now is usage, whether people pay and come back week after week.

The Working Product Stopped Being the Moat

Once the demand test succeeds in public, a competitor can rebuild the product with the tools that made it. Point a crawler, software that walks through a site and records the screens and behavior it finds, at a working product. Hand what it captured to a model and ask for the same thing back.

In February 2026 the developer Martin Alderson did that to Linear, a project management tool known for its engineering polish, recording his browser's network traffic while he used the app and handing the capture to a coding agent. Twenty or so prompts later, he wrote, he had a functional version of much of it, running on a standard monthly subscription. Each frontier release closes the gap further, and for the kind of product whose value is visible on its screens, the sort a first time founder usually starts with, the copy is already close enough to matter. What a crawl cannot see, the backend logic and the fixes accumulated over time, comes back wrong or missing. A 2026 benchmark named UI2App found the same split, the visual rebuild rated high and the inferred behavior far lower, several models near zero at carrying state from one screen to the next. But a customer comparing two offerings rarely sees those parts either.

Copying is not new. Instagram rebuilt Stories from Snapchat, and Amazon grew house brands around what sold well on its own marketplace. What changed is the price of following fast. It used to take an engineering team and a quarter. It is heading toward a subscription and a crawl.

A public validation win, the waiting list that fills, the launch post that travels, is also an advertisement to whoever is watching that the idea is worth copying. So the test has to cover more than demand. The MVP also has to show that the business is accumulating something a copy of the product does not get.

A moat, in the plain sense, is whatever keeps a competitor from taking the business after it is proven. A crawl gets the screens and the behavior, and little else. The data your users put in over months stays behind, along with the corrections and edge cases the product absorbed from real operation. The users stay behind too, which is why a cloned marketplace with no sellers is a rendering of a business rather than a business. So do the workflows your customers built around the product, and the pain of moving away from it. And the trust earned by handling money or regulated data carefully does not transfer, since careful handling is the review work the fast copy skipped. What defends a business lives outside the codebase, and it is the part a model cannot generate for you.

The audience is on that list as well, and it is a big enough subject to have its own piece here, on why reaching customers stays hard when building gets easy. The people are the one part of a business a crawler cannot even see.

Questions Before the Next Quick Build

Before you put a fast build in front of people, answer these. They can be applied whether you wrote it by hand or generated most of it.

• What is the one assumption this build exists to test? If it is whether people want the thing, a landing page may test it with less exposure than a working app.
• What would count as proof beyond a signup? A payment, or a second week of use without a prompt, says more than a waiting list.
• If the test succeeds in public, who sees it, and how fast could they ship the same screens?
• Six months in, what will this business have accumulated that a copy would start without?
• If it touches regulated data, a payment, or a login, has someone who can tell a sound build from a plausible one read what shipped?

How Long Will There Be a Business Here

The question an MVP was built to answer is whether there is a business here. That question still comes first, and the discipline Ries described still answers it. Build the smallest test that produces real learning, and let what people do decide. In randomized field experiments, founders trained to set a pass or fail threshold before running a test killed weak ideas faster and earned more on the ones they kept than founders who read the results after the fact.

The question that used to wait is how long there will be a business here. Founders were told to prove the market first and worry about defense at scale, and the order made sense while copying was expensive. It stops making sense when the copy can arrive on the same timeline as the validation. The moat question moved from the growth stage into the MVP, next to demand, because the release cycle that built your product will build it for whoever wants it next.

When you plan your next quick build, you will ask whether anyone wants it. What will you still own once they do?