AI Changed How MVPs Get Built. Here's Why Production Still Breaks.
Niresh LamsalHow AI Rewrote the MVP Process
Building is no longer the hard part. That sentence would have sounded absurd in 2021. Today it is the new baseline, and it is rearranging every assumption founders carry about how products get to market. This is not a piece about how fast AI is. You have read that piece already. This is a piece about what the speed actually means, where it breaks, and what founders should worry about instead of writing code.
What an MVP Actually Is?
The original definition
The term gets thrown around so loosely that it is worth pausing on what it originally meant. An MVP, or Minimum Viable Product, is the smallest version of a product that lets you test whether the idea has real demand. Eric Ries popularized it in The Lean Startup a decade and a half ago, and the core principle held up for years: build, measure, learn.
What changed
That definition has not changed. What changed is almost everything around it. Today, MVP gets used interchangeably with prototype, v1, beta, and sometimes just the product we shipped. The word has stretched to mean whatever the speaker wants it to mean. So if the idea of an MVP is the same as it was in 2011, what actually changed? The answer is the entire process of building one.
##The Old Way of Building an MVP
From idea to launch
For most of the last fifteen years, building an MVP followed a predictable rhythm. A founder had an idea. They sketched it out on paper, then sat with a designer for a few weeks turning rough flows into Figma mockups. By the end, there was a clickable prototype that looked real but did nothing yet.
The handoff problem
Then came the hard part: handing it off to a developer. If the founder was technical, they carved out nights and weekends. If they were not, they spent two months recruiting a technical co-founder or wrote a check to an agency. Development took months. Backend, frontend, database, auth, payments, deployment. Every line of code written by hand. Then QA, bug fixes, staging, production setup. Finally, several months later, the product launched.
H3: Why the old advice worked
Every stage required a different specialist. Every handoff cost time. The MVP was a relay race, and the baton passed through three to five sets of hands before it crossed the finish line. This is why Eric Ries's original advice made so much sense. When building was this expensive, the entire purpose of an MVP was to fail cheaply. Ship the ugliest version possible. Be embarrassed by it. Do not waste a year building something nobody wants.
That advice was load-bearing for a generation of founders. It is also now obsolete for a large class of products.
The New Way of Building an MVP
A different sport, not a faster race
The new process barely resembles the old one. It is not a faster version of the same relay race. It is a different sport entirely.
From idea to spec in an afternoon
A founder today starts the same way: with an idea. But instead of taking it to a notebook, they take it to Claude or ChatGPT. The AI pressure-tests the concept, names competitors the founder had not thought of, sketches the ideal customer profile, drafts a tight one-page spec. By the end of the afternoon, there is a clear plan.
From sketch to working UI in hours
The next morning, instead of opening Figma, the founder opens v0, Lovable, or Bolt and describes the UI in plain English. The tool returns working interactive code in minutes. Not a static mockup. Actual running software. The designer step does not disappear so much as collapse into the founder's chair.
From spec to shipped in days
Then comes development. The founder opens Cursor or Claude Code and starts a conversation. The AI scaffolds the entire project (auth, database, billing, deployment) in a single session. The founder reviews, runs, finds what is broken, asks for changes. Prompt, review, test, re-prompt. Hundreds of times across a few days.
This loop replaces what used to be three separate phases and three separate people. There are no handoffs because there is nobody to hand off to. Content and copy follow the same pattern. AI writes the landing page, onboarding emails, and help docs in one sitting. Launch is a git push to Vercel.
A reality check on the new numbers
For a software-only product with conventional architecture, total elapsed time runs one to four weeks. Total cost stays under $500 in tooling. Total team size is one person. This compression is not universal. Complex backends, regulated industries, hardware, ML pipelines, and deep integrations still take longer. But for the broad middle of SaaS, internal tools, content platforms, and simple marketplaces, the compression is roughly 20x compared to the 2019 baseline. That is not a faster relay race. That is a different sport.
The New Definitions
When the process changes this dramatically, the language has to update too. MVP used to mean a crappy prototype to test demand. Now it means a polished v1, because polish is free.
Minimum used to mean bare-bones features. Now it means whatever the floor is for not looking amateur. Validation used to happen through landing pages and fake doors before any code got written. Now building is validating.
Speed used to be about shipping fast to learn. Now it is about shipping fast to claim distribution. Moat used to be defined by what was hard to build. Now it is defined by what is hard to replace.
And risk used to be about whether you could build it. Now it is about whether you can stand out. That last shift is the whole essay in one line. The barrier to entry collapsed. The barrier to winning moved somewhere else: to distribution, taste, customer intimacy, and speed of learning.
The Cliff Between Prototype and Product
Here is the part most founders underestimate. AI gets you to a working MVP in days. A working MVP is not a production-ready product. The gap between those two things is wider than it looks, and it is where AI-built products quietly fail when they meet the real world.
We call this the cliff. The journey from idea to a real production system has roughly six stages: idea, prototype, the cliff, production engineering, hardening and safety, then launch and operate. Stage three is where most AI builds die. The platforms that got you to a working prototype were not designed to take you past it. That is not a criticism of those platforms. They are doing exactly what they were built to do. The mistake is using a prototyping tool as a production platform.
There are three common responses when founders reach the cliff. Some keep adding features and hope the underlying problems will fade. They will not. Some hire a cheap freelancer to make it production ready, which usually produces a slower prototype with the same problems. Some pause and rebuild it properly. Only the third group ships.
Four failure modes show up again and again at the cliff. A user enters something unexpected and the whole thing breaks in front of them. The AI confidently returns a wrong answer with no system to catch it. Costs run away because every click triggers an uncapped AI call. And the one nobody wants to discover after launch: one customer can see another customer's data. This is the most common Lovable and v0 failure we see in practice.
Security, the silent killer
AI-generated code often looks right and runs fine but ships with token-handling bugs, exposed API keys in client-side code, missing rate limiting, weak input validation, and no protection against the basics: SQL injection, cross-site scripting, request forgery. Secrets get committed to public repos far more often than founders admit. Row Level Security policies in Supabase are missing or misconfigured, which is how you end up with one customer seeing another's data.
The AI built what was asked. It was not asked to think like an attacker.
Compliance, the regulatory minefield
Depending on the market, GDPR, CCPA, HIPAA, or SOC 2 may apply, and the founder often does not know which. Cookie consent, data residency, audit logs, right-to-be-forgotten flows. Terms of service generated by AI but never reviewed by a lawyer. Each is a quiet liability waiting for the wrong customer or regulator.
Engineering quality, the technical debt nobody sees
Three related problems usually arrive together in AI-built products. Code works for ten users but melts at ten thousand because database queries got written for correctness, not performance, and indexes were never thought about. Patterns drift across the codebase, with the same problem solved three different ways in three different files. Tests exist but were never reviewed for actual coverage, so edge cases a careful engineer would catch go untested.
When a real engineering team gets hired six months later, the refactoring cost can erase the speed advantage AI delivered in the first place.
The honest takeaway
AI gets you to 80 percent in 5 percent of the time. The last 20 percent, the part that matters most when real customers and real money show up, still requires real expertise.
What This Looks Like in Practice
A founder came to Probits with a working v0 prototype of an AI brand visibility platform. The product tracks how brands appear across major AI engines (ChatGPT, Gemini, Claude, Copilot, Perplexity) and reports back to marketing teams on mentions, citations, and competitor positioning.
The prototype demonstrated the vision well. It also could not be launched. The codebase had no database indexing strategy. Open security rules let customers see each other's data. There was no caching layer. There were no tests. None of this was visible from the outside. The prototype looked like a product. It demoed beautifully. It just could not survive contact with real customers.
Over eight weeks, the production layer that the prototype skipped got built underneath it. Eleven missing database indexes were added, which reduced average query time on key endpoints by more than sixty percent. Row Level Security policies were corrected across every table, so customer data was actually isolated. A caching layer, connection pooling, and six critical slow query patterns were resolved across the dashboard and analysis views. Four injection points and three authentication flow gaps were patched. Unit and integration tests were added for core flows. The product shipped on Vercel with a separate staging environment, a written runbook, and an audit summary.
Total: seventeen issues identified, zero blocking issues at launch, eight weeks from concept to live.
The vision did not change. The frontend barely changed. What got rebuilt was the part underneath that the prototype tool had quietly skipped: the data layer, the security model, the cost controls, the monitoring. That is the work of the cliff, and it is rarely glamorous, but it is the work that decides whether the product survives its first real customer.
A Practical Checklist for Founders at the Cliff
If you have just shipped an AI-built MVP and are about to put a payment page on it, this is the moment to pause and check what you actually have.
A production AI system needs roughly twelve things in place:
- reliable data ingestion,
- defined fallback behaviour when the model fails,
- graceful error handling,
- monitoring of inputs and outputs and cost per request,
- real tenant isolation,
- human review points for high-stakes outputs,
- versioning of models and prompts and datasets,
- an evaluation harness for known inputs and edge cases,
- a governed prompt library,
- a security review covering prompt injection and data exfiltration,
- and an operational runbook for incidents and updates.
You do not need all of them before launch. You do need to know which ones are missing and which ones can wait. If more than three of those are missing and you have paying customers in the next thirty days, you are about to launch a problem.
The full breakdown with what each item actually looks like is in the document linked at the end of this post.
The Closing Thought
AI changed the build, not the bar.
An MVP today is faster, cheaper, and more polished than anything that was possible three years ago. The tooling is real. The compression is real. But the gap between shipped and production-ready still exists. It has not moved. It has not shrunk. It has just gotten easier to ignore.
The founders who win in this new era are the ones who use AI to move fast and know when to bring in real expertise to make what they built last.
AI can build your MVP in a weekend. Making it survive its first thousand users is still a different job.