An MVP 70% done with AI: what the last 30% costs

An AI-built MVP usually arrives with the same line: “it's almost done.” The screens are there. Login works. You can click from start to finish. And the next question is almost always the same: “how far are we from launch?”.

The honest answer almost always surprises. In November 2025, Addy Osmani, from the Chrome Developer Experience team at Google, gave this phenomenon a name in a talk streamed by Zed on November 6: the 70% problem.

What the 70% problem is

Osmani's idea is simple: “AI can rapidly produce maybe 70% of the code for an app, for a feature.” The first result is convincing. But underneath, the code can be fragile.

The remaining 30%, he says, didn't get cheaper with AI. The time spent on it is usually the same as before. And that's exactly the part that separates a demo from a product that holds up with real users.

Osmani shares a few numbers to show the distrust is widespread, not just among beginners:

• More than 30% of Google's code is already AI-generated.
• Developers' favorable view of AI in coding fell from 70% to 60% in two years.
• About 30% of developers say they have little or no trust in generated code.
• Realistic productivity gains sit between 1x and 2x, roughly 20% more tasks completed.

He also notes that many productivity stories come from new projects, with no legacy code. That's the case with your MVP. That's why the first 70% flies.

What's inside the missing 30%

In the talk, Osmani lists what usually gets left for the end. Here's how it shows up in a real MVP:

1. Edge cases. The user who signs up with the same email twice. The payment that drops midway. The empty field nobody tested.
2. Integration with production systems. Payment gateway, email delivery, invoicing, partner APIs. In the demo, everything is mocked. Live, each integration has its own rules, limits and errors.
3. Security. API keys in the right place, access rules in the database, protected routes. AI writes the happy path; security is the unhappy path.
4. The “two steps back” pattern. Osmani describes the loop where every fix you ask AI for creates a new problem. If nobody stops to understand how the parts connect, the project goes in circles.

What the 30% costs: effort, risk and time

I won't talk price here, because price depends on scope and only comes after discovery. But you can measure the cost of the 30% in three currencies every founder understands.

Effort

This is the part that needs someone who understands the code line by line. Osmani is blunt: if your name is on what shipped, you're responsible for what shipped. Reviewing code someone else (or an AI) wrote takes time, and code review has become the new bottleneck, he says.

Risk

The 70% rarely hurts anyone. The 30% does. A database without access rules exposes data. A poorly handled payment integration charges twice. A silent error produces a wrong report and a wrong decision. The risk doesn't show up in the demo; it shows up in the first month of use.

Time

Here's the trap. Since the 70% came out in days, the founder expects the 30% to come out in hours. It doesn't. By Osmani's account, the time spent on that part is still about the same as before AI. Whoever doesn't plan for this sets a launch, tells investors and then postpones, and the late software project becomes routine.

How do I know if my MVP is at 70% or 95%

A few quick questions help you get your bearings:

• Have you tested the app with two different users trying to see each other's data?
• Are the integrations (payments, email, APIs) running in production or still mocked?
• Can someone on the team explain how login and permissions work without opening the AI chat?
• What happens when an external integration goes down?
• Did each recent fix solve the problem or create another one?

If most of the answers are “I don't know,” you're probably at 70%.

How we do it at the Studio

We use Claude Code and Figma for design and build. AI speeds up the predictable part enormously, and I wouldn't give that up. The difference is that we treat the 30% as part of the scope from day one, not as a surprise at the end.

That's why the price is fixed after discovery and the deadline is written into the contract. That's how it went with AI Vou Eu, an AI travel SaaS, which went live in 4 weeks with the Studio. And every system ships with an AI agent that runs every day, flags failures, suggests improvements and checks whether the data makes sense.

With an inherited MVP, discovery starts with what already exists: we read the code, test the main flows, check security and data, and list what's missing for the product to go live. That list is what becomes the price and the date.

If your MVP is at 70% and you need to know, in numbers, what's left to launch, the Studio's project rescue starts with that math.