How Do You Build an MVP With AI?

AI can build the product. It cannot make it an MVP. AI app builders and coding agents turn a description into working software in hours or days, so for a standard web or mobile application, building is no longer the hardest part. What makes a first version a minimum viable product is what happens around the build: a validated problem, a deliberate choice of features, real customers and a definition of success. As I wrote in Innovation Mode 2.0, the definition of an MVP “is only an estimation; it is what the team believes will be proven viable.” AI writes the code. You test the belief.

• What AI does well: it generates screens, data models and working code from a description, drafts user stories and a backlog, and produces variations quickly. As the book says of the era of AI, “the backlog initialization and MVP definition are dramatically faster”
• What AI cannot do: talk to your customers, decide which problem is worth solving, or carry the risk of a launch. Those stay with the founder or the product manager
• Speed, as measured: the gains are real and smaller than the claims; see how fast you can build an MVP with AI
• Quality, as measured: generated code runs more often than it is safe. In Veracode's tests, published in March 2026, 45% of the coding tasks produced a known security flaw; see whether an AI-built MVP is secure enough to launch
• The scarce skill: when building is cheap, the decision about what to build carries the value. Steve Blank observed in September 2026 that a product built with AI on day one is no longer reliable evidence of customer discovery; see is the MVP dead
• Where to start: not with a prompt. Start with the problem, the users and the market, then let AI build what you decided. The seven steps give the order

You define the MVP in seven steps, and then you build it, release it and learn. The definition process in Innovation Mode 2.0 runs: set the context, understand the users, understand the market, refine the concept, frame the complete product, synthesize the MVP, and define success. It turns a product concept into a product definition with a prioritized backlog and “the cutline that defines the Minimum Viable Product (MVP).” With AI the steps stay: the drafting in each one gets faster, the conversations with users do not.

• 1. Set the context: gather what you already have: the problem statement, the idea, earlier research and any prototype. Identify the domain experts and stakeholders you will need along the way
• 2. Understand the users: identify the personas, their pain points and how each would benefit if the problem is resolved. Then choose the most important ones, because a good solution does not benefit all personas to the same extent
• 3. Understand the market: the demand, the structure, the dynamics and the competitive landscape, including the workarounds customers use today; see competitive analysis and market sizing
• 4. Refine the concept: generate competing solutions with AI-powered ideation, with other people, or in a design sprint for complex problems. Then review, combine and enrich them into one product concept
• 5. Frame the complete product: “think big, capture everything, prioritize wisely, and review often.” Describe the key features as Epic User Stories in a backlog that reflects the complete product
• 6. Synthesize the MVP: select “the smallest collection of features that delivers enough value to early customers so they actively use the product”; see how to decide what goes into the first version
• 7. Define success: name the KPIs and assign a goal to each. Only then build, release to real customers and learn; see how to define success before you launch

It is a prototype until real customers use it. What separates the two is not the quality of the code or the time it took. It is exposure to the market. As I wrote in Innovation Mode 2.0, “an MVP differs from a prototype or a proof of concept. Unlike these, MVPs are exposed to real customers,” and so they must be closer to production-ready. A product generated in a weekend is a fast and useful prototype. It becomes an MVP when you put it in front of customers with a hypothesis to test.

• The prototype question: does the experience work, and do people understand it? A weekend build answers this well; see the software prototyping guide
• The MVP question: do customers use it, return to it and, ideally, pay for it? Only real use answers this; see MVP, prototype and proof of concept compared
• Closer to production-ready: an MVP handles real data, real accounts and real mistakes. That means backups, error handling and privacy basics, which a weekend build often lacks
• The name Steve Blank proposes: Initial Untested Product, his label for the products that teams in his class generated with AI on day one
• How to cross the line: write the hypothesis, choose the first customers, define success, fix what real use would break, then release; see what breaks when real users arrive
• Use the prototype for what it is: showing a weekend build to five potential customers is one of the cheapest tests there is. Product experiments describes others that need no product at all

Before you build, you need four things: the context, the users, the market and a refined concept. These are the first four of the seven steps, and together they answer whether the product deserves to exist. In a company with a validation team they arrive as a package. A founder has to produce them. With AI the desk research and the drafting take days; the conversations with users take as long as they always did. Skipping them is the expensive shortcut, and the book describes the outcome to avoid: a product that “may be failing to solve the core problem for users, and the team is the last to know.”

• A problem worth solving: a statement of who has the problem, how often, and what it costs them; see how to frame a problem statement
• Evidence from users: in the book, user research “can validate the problem's importance and certain assumptions by asking participants how they are impacted by the problem”
• Problems, not feature requests: in the Y Combinator talk How to plan an MVP, Michael Seibel advises founders never to ask users for features. The user brings the problem: how often it occurs, how intense it is, whether they would pay to solve it
• A view of the market: who else solves this, how well, and what customers do today. Partial solutions and workarounds are signs of demand; AI market research shows how to get answers with sources
• One product concept: several competing solutions, reviewed and combined into the one you will build; see how to validate a startup idea
• Why this matters more with AI: among 385 startup shutdowns with a known cause, analyzed by CB Insights in 2026, 43% had poor product-market fit. Building faster does not lower that risk. It brings you to it sooner

You decide by defining the complete product first, and then selecting the smallest set of features that customers would actively use. In Innovation Mode 2.0, every feature in the backlog is scored on the value it brings to the user, its business impact, the effort to build it and its expected reach, plus its urgency. The top of that list is only a draft. A six-step method then challenges it, feature by feature, with two questions. The first: “Would the product be valuable (and viable) without this feature?”

• Nothing is thrown away: “the selection of features does not filter out items; it defines what to build first and what may follow through subsequent releases”
• Score every feature: value to the user, business impact, effort and reach. An overall priority score sorts the backlog and brings the good candidates to the top
• Add urgency: a valuable feature can still wait if it depends on other features, or on users who are not yet familiar with the product
• Challenge the selection: try to exclude each selected feature. Then ask the second question of each excluded one: “Is this feature necessary for the first instance of the product?”
• Look for cheaper versions: for the expensive features, find “smaller features and low-tech workarounds” that serve the same purpose
• Ask independent reviewers: people outside the team assess the selection “both as users and as entrepreneurs,” and a one-page summary of the scope lets others challenge it
• With AI: when a feature costs one more prompt, the cutline is harder to hold, not easier. The method in full is in how to prioritize features for an MVP and how to define the right scope

You define success by choosing the KPIs that matter and assigning a goal to each, before the first customer sees the product. As I wrote in Innovation Mode 2.0, success should be defined “by assigning goals to the selected KPIs, thus describing how the product should perform in the real world through numbers.” The definition covers both sides: the value generated for the user and the benefit created for the company. Without it, any result can be read as a success.

• The metrics: “user engagement, growth rates, market share, customer satisfaction, revenue, and profitability prospects.” Choose the few that reflect the hypothesis you are testing
• A goal for each: a number and a date, such as how many of the first customers return in the second week
• Value is not only revenue: “value is difficult to define; it is not always measured in terms of revenue or profitability”
• Growth over snapshots: one reading of the metrics can mislead. How they move from week to week says more about the product
• Instrument before launch: the product must record the events behind each KPI from the first day. Ask the AI that builds the product to add the analytics, then verify the numbers by hand
• Decide in advance what each result means: continue, change or stop. The signals to watch after launch are in how to measure product-market fit and how to measure whether an MVP is successful

Take one concept: a booking and payment link for independent tutors. It is an illustration made for this guide, not a case study. The founder has a prototype built with an AI app builder in a weekend, and three tutors who said they liked it. The seven steps turn that into an MVP definition in about two weeks. They replace three opinions with ten conversations, a list of forty possible features with four, and ‘they liked it’ with numbers that can fail.

• 1. Context: the prototype, notes from three conversations, and the founder's own years of tutoring. Missing: any evidence from tutors the founder does not know
• 2. Users: ten conversations with tutors the founder does not know, about the problem and not about the product. Of tutors, parents and students, the tutor is the most important persona: the tutor loses the income when a lesson is missed and would pay
• 3. Market: tutors manage today with a calendar, a messaging app and bank transfers. The workaround is free and familiar, so the product must save more time than it takes to learn
• 4. Concept: three competing solutions: a booking page, an assistant inside the messaging app, and a full management suite. Combined into one: a booking link with reminders and payment at booking
• 5. Complete product: forty epics, from lesson packages and reports for parents to group lessons and a marketplace for finding tutors. Everything is captured and scored
• 6. The MVP: four features: the booking link, reminders, payment at booking through an established provider, and a cancellation rule. The marketplace fails the test of the first instance: the product is valuable without it. No data about students is kept
• 7. Success: of 20 tutors invited, 10 take a booking through the link within two weeks and 7 still use it in the fourth week. Below that, the concept changes before more is built

The right tool depends on who will maintain the product and on what the MVP must prove. AI app builders turn a description into a hosted application and suit founders who do not code. AI coding agents work inside a code repository and suit people who can read and review what they produce. No-code platforms assemble standard components and suit standard workflows. And some hypotheses need no software at all. Choose the simplest category that puts the core scenario in front of real customers.

• AI app builders: you describe the product and receive a running application, hosted for you. Fast and accessible, with less control over the architecture. Check that you can export the code and the data
• AI coding agents: they write and change code inside a repository, under the direction of someone who can review it. Without that person, nobody checks what they produce
• No-code platforms: visual builders with ready-made components for forms, databases, payments and workflows. Predictable for standard products, limiting for unusual ones, and priced by usage as you grow
• No software at all: a landing page, a spreadsheet, or a person delivering the service by hand can test the same hypothesis; see concierge, Wizard of Oz and fake door experiments
• Questions for any tool: can you export the code and the data, where is customer data stored, what happens at a thousand users, and what does it cost per month at that point?
• Why categories and not product names: the products change every few months, and the choice between categories does not. The MVP guide lists the main AI tools for MVP development

Yes, for a first version, and with limits you should know in advance. AI app builders and no-code platforms let a founder who does not code release a working product to real customers. What they do not give you is the ability to judge what was built: whether it is secure, whether it holds when many people use it, and whether it can be changed safely. Plan for a technical review before launch, and for technical ownership once customers depend on the product.

• What you can do alone: define the MVP with the seven steps, build the core scenario, and test it with the first customers
• What you cannot judge alone: security, data handling and architecture. In Veracode's test of March 2026, 45% of the coding tasks given to AI models produced code with a known security flaw
• A cautionary case: in July 2025 The Register reported a founder's account of an AI coding agent that deleted the production database despite instructions not to change any code without permission and, in another error, created a database of fictional people. The restore that the tool had called impossible worked in the end
• What that case teaches: keep the live product separate from the version you experiment on, back up the data, and never give an AI agent permissions you would not give a new hire on the first day
• Buy review, not building: a first review of a day or two by an experienced engineer, on security, data and deployment, costs little next to the launch it protects
• When you need a technical partner: when the MVP shows demand and the code becomes an asset of the company; see when to rewrite or bring in engineers

A working first version can take days. An MVP still takes weeks, because the build is only one part of it. The measured gains from AI coding tools are real and far smaller than the multiples often claimed: a study of tens of thousands of engineers at Microsoft, published in 2026, found roughly a quarter more merged pull requests. The remaining time goes to deciding what to build, reaching customers, and making the product safe for real use. Plan in weeks, and spend the time you save on customers.

• What was measured: at Microsoft, engineers who adopted command-line coding agents merged roughly 24% more pull requests, and the lift lasted through the four months observed. The study is observational, and its authors note that a merged pull request is not the same as the value it delivers
• Feeling fast is not being fast: in a randomized trial by METR in 2025, experienced developers took 19% longer with AI while believing they were faster. METR now marks that result as out of date. Its follow-up of February 2026 shows some evidence of a speedup, and METR calls the data very weak evidence of its size
• The gain fades and the complexity stays: in 806 open-source projects studied at Carnegie Mellon, the gain in velocity was significant only in the first two months, while static analysis warnings rose 30.3% and code complexity 41.6%
• What I have not found: an independent measurement of new products built from scratch. These studies follow engineers in existing codebases, so read ‘an MVP in a weekend’ as a claim about the build
• The rule that predates AI: Michael Seibel's advice is to build a lean MVP “in weeks, not months”: time box the specification, write it down, and cut it when the deadline is at risk
• Where the time goes now: the four steps before any build, the search for the first customers, and the checks before launch

Build it yourself when the MVP is a standard application and you can have the result reviewed. Hire a freelancer when it needs custom logic or integrations. Hire an agency when you need a whole team for a few months and cannot form one. Whoever builds, three things stay with you: the definition of the MVP, the contact with customers, and the ownership of the code, the data and the accounts. AI has made building it yourself the cheapest option, which makes the definition more valuable.

• Build it yourself: with an AI app builder or a no-code platform, for a web or mobile product with standard features. You keep the speed and the learning, and you pay for a review before launch
• Hire a freelancer: for the parts that need an engineer, such as integrations, data migration or payments. Hand over the MVP definition, not a list of wishes; a PRD is the usual form
• Hire an agency: when you need a whole team for a few months. For the first version in a field with significant regulation or hard technology, which Michael Seibel calls a “heavy MVP,” the knowledge of the rules has to be in your own team, whoever builds
• Keep the ownership: the domain, the cloud account, the code repository and the customer data are registered to your company from the first day, whoever does the work
• Compare quotes on their basis: quotes for the same MVP differ widely. Ask each supplier for the hours, the rates and the running costs behind the number; see how much it costs to build an MVP
• If it is too expensive: the book's rule is to look first for cheaper ways to build the same features, “less fancy or less technologically advanced solutions that serve the same purpose,” and only then to reconsider the features that were marginal

What breaks is rarely the feature the founder demonstrated. It is what nobody asked the AI to build: the handling of wrong input, accounts and permissions, backups, payments that fail, and the separation between the test version and the live one. A product built with AI works on the path its builder described and is often untested everywhere else. Because an MVP is exposed to real customers, these basics are part of the word viable. Most of them can be checked in a few days.

• Data loss: keep the live product separate from development, back up the database, and test that you can restore it. In a founder's account reported by The Register, an AI coding agent deleted the production database despite instructions not to change any code
• Security flaws: generated code compiles far more often than it passes a security check; see whether an AI-built MVP is secure enough to launch
• Growing complexity: after adopting an AI coding tool, open-source projects showed 30.3% more static analysis warnings and 41.6% more code complexity. Every later change gets harder, so keep the scope small and ask for tests
• Instability: in the DORA research of 2025, AI adoption goes with higher delivery throughput and with lower delivery stability. More changes, shipped faster, need automated tests and a way to roll back
• The unhappy paths: wrong input, a double click, an expired session, a failed payment, an empty list. Walk through the core scenario as a careless user would
• Costs that grow with use: hosted platforms and AI features charge by usage. Estimate the monthly cost at a hundred customers and at a thousand before you set a price
• Support: give customers a way to report a problem and a person who answers. At this stage every complaint is research

Not by default. In tests published in March 2026 by Veracode, which has tested more than 150 AI models to date, 45% of the coding tasks produced code with a known security flaw when the prompt gave no security guidance. The rate has stayed almost flat for two years, while the share of generated code that compiles rose to 95%. Veracode sells security testing, so read it as a vendor's study with a public method. Treat generated code as code nobody has reviewed, and have it checked before customers trust you with their data.

• Where the models do well: in the same test, they avoided SQL injection in 82% of the tasks and insecure cryptography in 86%
• Where they fail: they avoided cross-site scripting in 15% of the tasks and log injection in 13%. Veracode's explanation: the models recognize surface patterns and fail where they must follow user input across several lines or files, as forms and accounts require
• Ask for security: the test measured what models do without guidance. Stating the requirements in the prompt (validation of input, encryption of personal data, no passwords or keys in the code) is a sensible precaution, not a guarantee
• Scan and review: run a static analysis scan, and have an experienced engineer review sign-in, payments and access to data before launch
• Hold less data: the safest data is the data you did not collect. A first version rarely needs more than an email address and what the core scenario requires
• Use proven services for the risky parts: sign-in, payments and file storage from established providers, not generated from scratch
• Regulated fields: in health, finance or products for children, the law sets the bar for viable; see when MVP thinking is harmful

Bring in engineers when the product has shown demand and the code has become the constraint, and rewrite only the parts that block you. Until customers return and the numbers you defined are met, the MVP is an experiment and its code is replaceable. After that, the code is an asset and needs an owner. The signals are practical: every change breaks something else, the same defects come back, costs grow faster than usage, or a customer asks a security question you cannot answer.

• Before demand, improve the product: as I wrote in the book, “an initially unsuccessful launch can be transformed into a successful product through a series of fast development iterations.” Rewriting code that serves a product nobody wants is the wrong investment
• After demand, review first: an engineer's review tells you what to keep. A rewrite can often be limited to parts, such as sign-in, payments or deployment
• What carries over: the scenarios customers validated, the scope and the metrics. They are the specification of the next version; see how to write the PRD
• Why waiting has a cost: in the Carnegie Mellon study, warnings and complexity stayed higher after adoption, and the authors found that this slows later development
• What the inexpensive start bought you: in the book's words, “building a good, inexpensive first release preserves degrees of freedom for the product.” The money you did not spend on the first build pays for the rebuild that the evidence justifies
• Who to bring in: one experienced engineer who owns the architecture before any larger team; see how to build a product development team

Building with AI is about how the product is made. An AI product is about what the product does. An MVP built with AI can be an ordinary application. The MVP of an AI product has a model inside it, so its behavior varies, it can be wrong with confidence, and its quality has to be measured. Its definition needs three additions: what good output looks like, how the output is evaluated, and what the product does when the model fails. The seven steps apply to both.

• Built with AI: the tools are AI and the product may contain none. Its risks are the ones in this guide: security, reliability and a scope that grows too easily
• An AI product: the value depends on what a model produces. Its risks are accuracy, consistency, the cost of every request and the data it needs
• Define good output: examples of acceptable and unacceptable answers belong in the MVP definition; see how to write a PRD for AI products
• Evaluate before and after launch: a set of real cases, run again on every change to the prompt or the model; see AI engineering for product teams
• Design for failure: decide what the user sees when the model is wrong or unavailable: a fallback, a person, or an honest message
• Test the value without the model: in a Wizard of Oz experiment a person produces the output behind the interface, which shows whether customers want the result before you invest in producing it
• Count the cost of use: every request to a model has a price. Add the cost of serving one customer to the definition of success