You Built an MVP With AI. Keep It, Fix It or Rebuild It?

A business owner can now build a working first version of a product without a contractor and put it in front of real users. That changes what the next stage should look like, who should build it and what it should cost.

SHORT ANSWER

Keep, Fix or Rebuild

If you built an MVP with AI and people are using it, you already have the most valuable part: evidence of what users do and what they will pay for. Whether the code itself survives depends on what the product has to carry next. A narrow internal tool with a few users and no sensitive data can often stay as it is. A product that is starting to take payments, store personal data or serve customers usually needs to be hardened, and sometimes rebuilt on a new base. The right first step in every case is the same: find out what can be kept before anyone proposes to rewrite everything.

The term vibe coding appeared in early 2025, when Andrej Karpathy used it for building software by describing what you want to an AI model and accepting what it writes. A year and a half later, platforms that generate, test and deploy an app from a text description are an ordinary tool. For a narrow enough task, the owner can assemble a working version over a weekend, give it to customers or employees and watch what happens.

That shift lowered the cost of an attempt more than the cost of software itself. For an owner who expects to spend $50,000 to $100,000 on the next stage, it also changes the questions worth asking before that money is committed.

THE NEW FIRST MEETING

The Conversation Has Changed

For years the first conversation between a business and a development team started with an idea and a question: "How much does it cost to build an MVP?" Everything after that rested on assumptions about how users would behave, so the budget paid for the build and for the risk of guessing wrong.

Now the conversation increasingly starts in a different place. The owner opens a laptop and says: "I built the first version. Here is how people use it, here is where they drop off, and here is what they are ready to pay for. Help me develop it." It is a different order: fewer assumptions and more observed behavior. An owner can also explain a process through a working example far more precisely than through a long specification, because the example shows what the words leave out.

Some of these experiments will end without any agency at all. The hypothesis may not hold, or the tool may turn out to be good enough for its small job. That is a normal outcome, and the owner saved the money a contractor would have charged to learn the same thing. We wrote about the earlier version of this decision in Do I Need a Developer, or Is AI Enough?, and the answer has moved further toward trying first.

WHAT IT PROVED

What Your MVP Already Did

It is easy to dismiss a home-made product with the phrase "it's only a prototype". If the version lets you test the main assumption on real users, it has already done the most expensive work in early product development: it replaced a guess with data. We have argued before that an MVP is the cost of entry, not a cheap product, and an AI-built version pays that entry fee at a fraction of the old price.

What usually survives the next stage, even when the code does not:

• the core user flow that people actually completed, step by step;
• the screens and wording that users understood without help;
• the data collected so far, along with what it says about demand;
• the list of features nobody touched, which is often the most useful list of all;
• the owner's own understanding of the process, sharpened by building it.

AI made software cheaper to build, and much cheaper to try.

A team that receives this material starts from evidence instead of a brief, which should make the next stage cheaper and less risky.

WHERE IT BREAKS

Where AI-Built MVPs Break

The limits of a vibe-coded product rarely show up in a demo. A test with limited access and harmless data is one thing; a public system with payments, personal data and obligations to customers is another. Security and correctness checks should match those risks from the moment real customers arrive, not only after demand is proven.

The research is consistent on this point. In its 2025 GenAI Code Security Report, Veracode tested more than 100 language models on 80 coding tasks and found that 45% of the generated code samples introduced vulnerabilities from the OWASP Top 10, with cross-site scripting defenses failing in 86% of relevant cases. In 2025 a researcher also found that more than 170 projects built on the Lovable platform exposed data because database access rules were missing: emails, phone numbers, payment status and API keys were reachable by anyone who knew where to look. The issue was registered as CVE-2025-48757.

Neither finding means AI-written code is bad by nature. They mean that a model writes what it was asked for, and nobody asked it about access rules.

The weak points we look for first are almost always the same:

• who can see and change which data, and whether the database enforces it or only the interface;
• passwords, API keys and payment credentials stored in code that runs in the browser;
• backups, and whether anyone has ever tried to restore one;
• version history: many projects we see are not kept in any repository, so there is no record of what changed and when;
• tests, or at least a repeatable way to check that a change did not break the payment flow;
• the one person, often the owner, who knows which prompts produced which part of the system.

Each of these is fixable, and some are cheap. Together they decide whether the product can take the next hundred customers or will fail in front of them.

COME EARLY

When to Bring It In

Owners often wait to show a product to a development team until it feels finished, as if a rough version were something to apologize for. We would rather see it early. A raw first version, even one built on simple logic, already tells us more than any brief: what people use, where they stop and what they ask for. The sooner we see it, the cheaper every change is, including the changes in product logic that the data from the MVP sometimes suggests.

The right moment to talk is when you feel ready for that conversation, and the product does not have to be perfect by then. If you have built something and people are using it, that is enough to start the conversation. The next stage is usually more than a final push: what exists has to be hardened, flows that worked for the first users have to be ready for the next thousand, and sometimes the data points to a better product than the one you planned. This is where the work becomes interesting for both sides, because finishing an app turns into building a business around it.

Being ready usually means three things: people are using the product, you know what the next stage has to carry, and you have set aside a budget for it. When all three are in place, the first step is an MVP Review, which we describe at the end of this article.

It is also an interesting time, because AI brings relief and tension at once. It amplifies good ideas and good products, and it wipes out weak ones faster than before. What it does not supply is the idea itself, or the analytical and product thinking that turns an idea into something people pay for. That part is still built together: the owner brings the knowledge of the market and the customers, and the team brings the experience of how products grow.

THE DECISION

Keep, Fix or Rebuild

The decision is not a matter of taste or of what a contractor prefers to build. It follows from what the product has to do next.

Even a rebuild does not start from zero. The flows, screens, data and lessons from the first version carry over, and the new system is designed around behavior that has already been observed. The expensive mistake is choosing a rebuild before anyone has checked what could stay. Choosing the wrong foundation costs more later, as we explained in The Hidden Cost of Choosing the Wrong Architecture, but rewriting a working product without a reason costs money right now.

A working MVP is evidence. Its code is a separate question.

SMALLER TEAMS

Smaller Teams, Different Quotes

The same tools that let an owner build a first version are changing the teams that build the next one. Two or three strong specialists can now handle some projects that used to need ten or fifteen people, especially when most of the old work was implementing well-defined functions and the requirements and architecture were clear.

Two separate gains are often mixed up here. "Five times fewer people" and "five times faster" are different claims, and they cannot simply be multiplied. When the team and the calendar shrink at the same time, the only fair comparison is the same scope, the same quality, the same integrations and the same responsibility after launch. Even careful measurements are uneven: in early 2025 METR found that experienced developers with AI tools were 19% slower on real tasks while believing they were faster, and its February 2026 update called the newer, more positive data very weak evidence.

Our own numbers are modest, and that is why we trust them. Peretz's internal sales system, covering leads, projects and invoices, was built in about a month by one senior developer, a tester and Claude, with an architect checking the work. Moving this site from Laravel 7 to Laravel 13 took three days. In both cases the speed came from people who knew what to build and could verify what the AI produced, which is where the real cost of AI sits.

Fewer people and faster delivery are two different gains.

The shift has a human cost. The cuts fall mostly on junior and mid-level specialists, whose work was exactly the well-defined implementation AI now does fastest. Stanford's Digital Economy Lab, using ADP payroll data, found that employment of 22- to 25-year-olds in the occupations most exposed to AI, software development among them, fell about 16% relative to less exposed jobs by October 2025, while older workers in the same roles held steady; the authors note that AI is not the only cause. Some of these people will retrain, because the market now pays for judgment more than for typing. Others will build their own products in the niches they know, which means more owners will arrive with a first version already in hand.

For a buyer this has a practical consequence. Contractors who mainly sell hours of manual programming will have to shrink their teams, lower their prices or find far more work. Compact teams that can design, build and check a system can take on a larger category of contracts than before. When a proposal lists twelve people for nine months, it is fair to ask what each of them does that the tools do not, and whether the price includes the work after launch or shifts it there.

BEFORE YOU PAY

Questions Before You Pay

Before committing the next budget, whether to us or anyone else, these questions are worth asking out loud:

1. Which parts of my MVP do you keep, and why? A team that proposes to rewrite everything before looking is selling a build, not a solution.

2. What exactly gets rewritten, and what problem does each rewrite solve?

3. Who reviews the code the AI writes, and how? "We use AI" says nothing about verification.

4. Where will the repository live, and who owns it, along with the domain, hosting and data?

5. What happens to my users and their data during the move? A good plan keeps the old version running until the new one is proven.

6. What does the price include after launch? Support, fixes and updates are part of what you are buying.

7. If the team is large, what does each person do? The question is not hostile, and the whole market is asking it now.

A contractor who answers these calmly is worth talking to. One who answers the first question with "we'll need to start fresh" before seeing the code has told you something important.

HOW WE WORK

What We Do With a Founder's MVP

When an owner brings us a working version, we start with what the product has already proven and what it has to carry next: customers, payments, data, integrations, other markets. Then we look at the code and the infrastructure through the list above and sort everything into what stays, what gets fixed and what has to be rebuilt. In many cases the honest answer is that a large part can stay.

One project we are working on now shows what this looks like in practice. A client came to us with a very raw MVP of a platform that uses AI to monitor news and world events around the clock and connect them to companies and industries. The logic was simple, but it showed the idea working. The platform does not trade and has no influence on prices or markets: when something critical happens, users receive an alert and decide for themselves whether to react and whether to buy or sell a particular type of asset. We cannot name the client or describe how the system works until it launches. What we can say is that the raw first version was worth having, because it gave the next stage a concrete starting point instead of a description.

Not every product needs us. An owner with a small internal tool may only need backups and a repository, which a freelancer can set up in a day.

For us, this is also a new kind of client. We used to receive ideas that still had to be tested. Now we increasingly receive small products that have already been tested and need help becoming reliable business tools. That is a better starting point for everyone. For a first version, the place to start is the MVP Review. If the product already works as a business and the question is where to take it next, a strategic session is the better format. And if the product is turning into the core of how the company works, it becomes a business digitalization project rather than an app.

MVP REVIEW

Why the Review Comes First

The most expensive mistake at this stage is rarely a bug. It is putting $50,000 to $100,000 into the next version of a product the market does not need in that form, or building on a base that will have to be replaced a year later. The person who built the first version is the least objective judge of either question, and that is natural: they have spent weeks on it and can already see what it could become. An outside review costs a fraction of the next stage and answers both questions before the money is committed.

That is why we made the MVP Review a separate service with its own team. It looks at the product from three sides:

• Technical. Our developer and architect check the code, security and infrastructure: access rules, keys and payment data, backups, the repository, and whether the structure will hold more users, features and markets.
• Product. A product strategist reviews what the usage data shows, which flows work, where people stop and whether the logic of the product or its interface should change.
• Market and business. Valeriya Chumachenko, our advisor with more than ten years in technology M&A, looks at whether the market needs the product, who will pay for it and how much, and how an investor or a buyer would see it.

The third part is what most code audits leave out, and it is often the most valuable. A product can be technically sound and still not worth the next investment, or rough in the code and clearly worth fixing because people keep coming back to it. Knowing which of these cases you are in is worth more than any list of bugs.

The result is a written report with a verdict on each part of the product (keep, fix or rebuild), the critical risks to fix before real customers or payments arrive, recommendations on the product logic, an estimate of the scope and budget of the next stage, and a call where we walk you through it all. The review starts at $3,000 and usually costs $3,000 to $5,000, depending on the size of the code, the number of integrations and whether money or personal data moves through the product. It is paid in advance and is not credited toward later work, because several specialists work on every review and the report is useful whether or not you continue with us. You can take it to any team.

FAQ

Sources

• Veracode: 2025 GenAI Code Security Report
• Superblocks: Lovable vulnerability explained (CVE-2025-48757)
• Stanford Digital Economy Lab: Canaries, interest rates and timing (February 2026)
• METR: Measuring the impact of early-2025 AI on experienced open-source developer productivity