The 80% Problem: Why AI-Built Apps Stall Before They Ship

Quick answer: The 80% problem is the pattern where AI and no-code app builders get a founder roughly 60-70% of the way to a real product in days, then stall on the hard final 30-40% - real authentication and multi-role access control, third-party integrations and their failure paths, data correctness, and security. That remaining slice is architectural, not cosmetic, and it cannot be bolted on after the fact.

If you have built an app with an AI tool, you already know the shape of this. The first weekend felt like magic. You described a product, watched it appear, clicked through screens that looked finished, and showed it to people who said it looked real. Then you tried to put actual users on it, connect a payment processor, and let two different kinds of people log in - and progress fell off a cliff. The demo was 70% done. The product was not.

This is not a tooling failure or a sign you picked the wrong builder. It is a predictable property of how these tools work, and it has a name. Andrej Karpathy popularized "vibe coding" for the build-by-describing workflow. Addy Osmani, an engineering leader at Google, named the wall you hit afterward in his December 2024 essay The 70% problem: hard truths about AI-assisted coding. His observation: AI gets you most of the way fast, but "that final 30% - the edge cases, the security considerations, the production integration - remains stubbornly difficult." The percentages shift with the project. The wall does not move.

This page is the map of that wall. It explains what is actually in the last 30-40%, why AI builders systematically skip it, why it has to be designed in rather than patched on, and how to think about closing it.

Why the first 70% comes so easily

AI builders are extraordinary at the part of software that is visible and pattern-heavy. Layouts, forms, navigation, a list view, a detail view, a settings page - these are the most common shapes in all the code the model trained on, and they are exactly what a demo shows. When you ask for "a dashboard with a table and a filter," the tool has seen ten million of those and produces a convincing one in seconds.

That is genuinely valuable. Getting to a clickable, real-looking prototype used to take a small team a few weeks. Now it takes an afternoon. For validating an idea, aligning a cofounder, or showing an investor the shape of the thing, the first 70% is often enough.

The trap is mistaking visible completeness for actual completeness. The screens that make a product feel done - the ones you look at - are the easy 70%. The work that makes a product safe to put real users and real money through is mostly invisible, and that is the part the tool quietly leaves out. We cover the maintainability side of this gap in vibe coding technical debt; this page is about the functional gap that stops you from shipping at all.

Real auth is the first wall, and it is a data-model decision

Almost every AI builder demos a login screen on day one. A login screen is not authentication. It is the doormat in front of it.

Real auth answers harder questions. Who can see this record? Can a staff member edit an order but not delete a customer? Can a customer see their own invoices but no one else's? When you invite a teammate, what exactly can they touch? These are access control questions, and the answers have to live in your data model - in how rows relate to users and roles - not in which buttons you hide on the screen.

This is where AI-built apps fail most dangerously, because hiding a button is easy and the model does it happily, while enforcing the rule on the server is the part it skips. If the only thing stopping a customer from reading another customer's data is that the "edit" button is not rendered, anyone who opens the browser network tab can call the endpoint directly and get the data anyway. The demo passes. The app is wide open.

Multi-role access control has to be designed in because it dictates the shape of your tables. Retrofitting roles onto a schema that assumed a single kind of user often means rewriting the data layer - which is why it stalls projects rather than slowing them. We go deep on the right way to do this in adding authentication to an AI-built app.

Integrations break, and the failure paths are the actual work

The second wall is third-party services. Payments, email, SMS, calendars, shipping, any external API. The builder will happily generate the call that works. The call that works is maybe 20% of the integration.

The other 80% is everything that happens when the call does not behave. Stripe times out after you have already created an order. The webhook that confirms a payment arrives twice. An email provider returns a 500 and your signup silently fails. A user double-clicks "Pay" and your code runs twice. None of these show up in a demo, because a demo makes one clean call and gets one clean response.

Handling them correctly requires concepts that no prompt implies and the builder will not add on its own: idempotency keys so a retried request does not charge twice, webhook signature verification so you can trust the event, and dedup logic keyed on the event ID. Stripe's own guidance is explicit that "the same event may be delivered more than once" and that you must process events idempotently. An AI-built payment flow that skips this will, eventually and silently, double-charge a real customer. We walk through getting this right in adding Stripe payments to an AI-built app.

This is also why integration-heavy apps stall hardest: every external dependency adds its own failure surface, and the builder treats each one as a single happy-path call.

Data correctness is invisible until two users collide

Demos run with one person and a clean database. Real apps run with many people acting at the same moment on shared data, and that is where correctness quietly breaks.

Two staff members fulfill the same order at once. A balance is read, decremented, and written back by two requests that interleave, and the final number is wrong. Inventory goes negative. A total in a summary table drifts away from the rows it is supposed to sum. These are concurrency and consistency problems, and the generated code almost never accounts for them because, under a single-user demo, the race never happens.

You cannot test your way to this after the fact by clicking around - the failure only appears under real, simultaneous load. It has to be prevented in how you write and read data: transactions, constraints the database enforces, and a deliberate decision about what happens when two writes conflict. This is structural, and it is one of the main reasons apps that worked fine with ten users start corrupting data at a few hundred. The scaling version of this story is in no-code app scaling problems.

Security is enforced at the database, not the screen

The security gap deserves its own wall because the numbers are stark. Veracode's 2025 GenAI Code Security Report, which tested code from more than 100 large language models across 80 coding tasks, found that 45% of AI-generated code samples failed security tests and introduced an OWASP Top 10 vulnerability. The report also noted that newer, larger models were no better at security than older ones - this is a systemic property, not a bug that the next model release fixes.

For a founder, the concrete version is this: the generated code tends to trust the client. It assumes the request came from the right user, asking for their own data, with permission to do what it is doing. Real security assumes the opposite and checks every time, as close to the data as possible.

The cleanest way to do that is to enforce access at the database row level, so that even if your application code has a bug, the database still refuses to hand a user someone else's rows. Supabase's Row Level Security documentation describes the pattern: policies on each table that scope every read and write to the authenticated user. This is the kind of thing that has to be in the schema from the start. Bolting it on after launch means auditing every table and every query you already shipped. We break down the specific risks in vibe coding security risks.

Why "just ask the AI to fix it" does not close the gap

The natural instinct is to keep prompting. The app is 70% done, so surely a few more good prompts finish it. This usually makes things worse, for two related reasons.

First, the hard 30% is mostly things you have to know to ask for. You will not prompt for idempotency keys, row-level policies, or transaction boundaries if you do not know those concepts exist - and the tool will not volunteer them, because nothing on the visible screen demands them. This is the knowledge paradox Osmani describes: AI accelerates people who already know what to ask, and leaves everyone else building confidently on top of gaps they cannot see.

Second, each new prompt adds code on top of foundations that were never designed for it. Bolting multi-role access onto a single-user schema, or wedging retry logic into a payment flow that assumed one clean call, produces fragile patches that interact badly with each other. The app gets more complicated without getting more correct. This is the exact mechanism behind why AI builders get requirements wrong: the tool builds precisely the narrow path you described and nothing around it, so the gaps compound rather than close.

The last 30-40% is not more of the same work. It is a different kind of work - architectural decisions about data, trust, and failure - and you cannot prompt your way to architecture you have not decided on.

It has to be designed in, not bolted on

The single most useful idea on this page: the hard 30-40% is load-bearing. Auth roles shape your tables. Idempotency shapes how you write to the database. Row-level security shapes your schema. Concurrency safety shapes how every write is performed. These are not features you add to a finished app - they are properties of the foundation the app sits on.

That is why the gap stalls projects instead of merely slowing them. When the security model, the role model, and the failure handling all need to be retrofitted at once, you are frequently rebuilding the data layer the rest of the app depends on. The work that looked like the last 10% turns into a rebuild of the first 70%, which is exactly the rescue pattern playing out across thousands of vibe-coded apps right now.

The lesson is not "do not use AI builders." They are the fastest way in history to get to 70% and validate that you are building the right thing. The lesson is to be honest about which 70% you have, and to plan for the rest before you put real users, real data, and real money on top of it.

How to actually close it

Once you have a validated prototype and you are ready to ship something people depend on, there are two honest paths through the last 30-40%.

The first is to bring in an experienced developer - not to rewrite your prototype for fun, but to make the four architectural decisions the tool skipped: the role and access model, row-level security, integration failure handling, and concurrency-safe writes. Hand them the prototype as the spec. It already shows what you want; the job is to build the foundation it should have been standing on. Be clear-eyed that this is real engineering work and price it accordingly.

The second is a managed build, where a team takes the prototype and ships a production version with the hard parts designed in from the start. This is the model behind Creatr (also called DeepBuild): you keep the speed of having validated the idea fast, and the production app is built with real auth, handled integration failures, correct data, and database-level security as foundations rather than afterthoughts.

Either way, the move that does not work is shipping the 70% and hoping the rest never matters. It always matters, usually the first time a real customer hands you real money. The 80% problem is not a reason to avoid AI builders. It is a reason to know exactly where they stop - so you can decide, on purpose, who builds the part that has to be designed in.