Reality check · October 19, 2026

Your AI Prototype Is 20% Done: The 70% Problem, Explained

AI tools get you a convincing demo fast. The last 30% decides whether clients can use it. What lives in that gap, and how to plan for it in a service business.

There is a moment every vibe coder knows. You have spent a weekend describing your idea to an AI tool. The screens look right. The buttons work. You show it to your business partner and they say, "Wait, you built this?" It feels nearly finished.

It is not. And the two most-read pieces of writing about AI-assisted building explain why.

Two people, one finding

In December 2024, Addy Osmani, an engineering lead at Google, published The 70% problem: hard truths about AI-assisted coding. It became one of the most shared essays on the subject. His observation: people without engineering experience can now get about 70% of the way to working software remarkably fast. The final 30%, the part that makes software "production-ready, maintainable, and robust," still takes real engineering knowledge. In a later update he added that the last 30% usually takes longer than the first 70%.

A few months later Andrej Karpathy, the person who coined the term "vibe coding," arrived at the same place from the other direction. He built a small app called MenuGen and wrote about putting it online. The working demo on his laptop came together quickly. Then came hosting, logins, payments and configuration. His verdict: "I felt like I was 80% done but... it was a bit closer to 20%."

One is a Google engineering leader. The other is one of the best-known AI researchers alive. Both hit the same wall. If you hit it too, you are in good company, and you are not doing it wrong.

Why the first 70% is so fast

AI tools are extremely good at the visible parts of software. Screens, layouts, forms, buttons, the happy path where a user does exactly what you expected. These are the parts that have been built millions of times before, so the AI has seen countless examples.

They are also the parts you can judge yourself. You can see whether the quote form looks right. You cannot see whether it stores a client's phone number somewhere anyone on the internet can read it.

That is the trap. The progress you can see is the progress that is easy to make. The work that remains is the work you cannot see.

What actually lives in the last 30%

Here is the last 30%, translated into what it means for a service business tool. Take an example: a home services company building an online booking and quoting portal for customers.

Real users do unexpected things

Your demo works because you know how to use it. Customers will enter a zip code with a typo in it, leave the square footage blank, double-click the "book" button, open the page on a six-year-old phone, and try to book a slot that someone else just took. Osmani's examples are exactly these: empty values the code did not expect, two things happening at the same time, inputs nobody planned for.

Accounts and permissions

The moment customers log in, every page has to answer one question correctly: is this person allowed to see this? A customer must see their own bookings and nobody else's. Your technicians must see today's jobs but not your margins. AI tools often build the login screen beautifully and get the permission rules quietly wrong. In one study of apps built on Lovable, about one in ten exposed their data to anyone who knew where to look. Our security checklist covers this in detail.

Money

Taking a deposit sounds like one feature. In practice, Karpathy found his AI had linked payments to customers by email address, which breaks the moment someone uses a different email at checkout. He had to rework it. Payment systems also need a separate test setup and live setup, and the app has to confirm on its own server that a payment actually happened, rather than trusting what the customer's browser says.

Everything around the app

Hosting, a domain name, secret keys that must not end up in public code, email that actually arrives, backups. Karpathy lost an hour just because his secret keys were stored on his laptop and never made it to his hosting provider. None of it is difficult on its own. All of it together is where the weekends go. We walk through each piece in Where does a vibe-coded app actually live?

Change without breakage

Osmani describes a pattern he calls "two steps back." You ask the AI to fix one bug. The fix breaks something else. You ask it to fix that, and a third thing breaks. Experienced engineers can see why. Non-engineers, in his words, "lack the mental models to understand what's actually going wrong." This is also where costs climb, because most tools charge for every attempt. See what vibe coding really costs.

Someone has to own it

Software is never finished. Clients ask for changes, the tools it depends on update, something breaks on a Sunday. Jason Lemkin, the founder of SaaStr, built several production apps with AI and wrote up what he learned. His advice includes budgeting about a month for a real business app, spending around 60% of that time on testing, and deciding up front who will maintain it.

Osmani's name for it: house of cards code

Osmani's sharpest phrase is "house of cards code": software that "looks complete but collapses under real-world pressure." That is the risk for a service business specifically. Your reputation is your product. A tool that works in the demo and fails in front of a client does more damage than no tool at all, because it fails under your name.

How to work with the 70% problem, not against it

None of this means you should not build. It means you should know which part of the job you are doing.

Use the fast 70% for what it is great at. Prototypes are where AI tools shine. Build the demo. Click through it. Show it to five clients and watch their faces. You will learn more in a week than in a month of planning, and it costs you almost nothing.

Plan before you prompt. Osmani found that better specifications push the fast part from about 70% to roughly 80–85%. Write down who uses the tool, what they do, and what must never happen before you open any AI tool. Our guide to writing a PRD before the prompt has a template.

Keep each step small and reversible. Osmani recommends a fresh conversation per task, a narrow focus, and saving a working version after every change. When the AI starts spiraling, go back to the last version that worked rather than asking it to fix its fixes.

Decide early whether this is a sketch or a foundation. For an internal tool, the demo may be enough. For anything clients log into, pay through or trust with personal data, treat the prototype as a very good sketch. The decisions it captures are valuable. The code may not be what you build on.

Budget the last 30% honestly. Lemkin's month per app with 60% of it on testing is a reasonable starting point for someone doing it themselves. If you cannot spare that, the honest answer is to get help for that part.

A quick self-check

Before you call your tool "nearly done," ask:

Could a stranger see another customer's data by changing a number in the web address?
What happens if two people book the same slot at the same moment?
Where are your secret keys, and could anyone find them in the page's code?
If a payment fails halfway, what does the customer see, and what does your team see?
Is there a backup, and have you ever restored from it?
Who fixes it at 7am on a Monday when a client calls?

If you cannot answer most of these, you are somewhere in the last 30%. That is normal. It is just not done.

Where the leap actually is

The 70% problem has a business consequence beyond the technical one. Because the first 70% is now cheap and fast for everyone, a convincing demo is no longer an advantage. Any competitor can produce the same one this afternoon. What separates a tool your clients pay for from a weekend project is the last 30%, plus the harder question of what is worth building at all.

That is why we work the way we do at Veyra. You get a working prototype first, before any money changes hands, so you can see and click through the idea. Then we build the part that is invisible in a demo: the security, the payments, the edge cases, and the ongoing ownership. We stay on as product lead after launch, and two of the three ways we are paid depend on what the product earns.

If you have a prototype that is "nearly done," or an idea you have not started, book a call. We will tell you honestly which part of the job is left.