Launchr

How often do AI-built apps fail?

Published 20 August 2026 · Data collected 17 June – 24 July 2026 · Launchr Pty Ltd

Across 387 AI builds run through our own factory, 27.6% could not reach a working, shipped state without a human stepping in. For apps with a real backend that figure was 39.1%. For static sites, games and simple tools it was 6.0%. The gap between those two numbers is the whole story.

387build records analysed
27.6%never shipped unaided (107/387)
39.1%failure rate, backend apps (97/248)
6.0%failure rate, static apps (8/134)

Why publish this

Almost every claim about AI-built software is an adjective. Tools are “fast”, results are “production-ready”, failures are “rare”. We could not find a single published figure with a denominator attached, so we measured our own factory and published the number — including the parts that make us look worse.

We are not a neutral party. We sell a service that fixes this problem. That is exactly why the method and the limitations are set out in full below: so you can check the arithmetic rather than take our word for it.

Method

Every build our pipeline runs writes a telemetry record. This analysis reads those records directly from the production system — one record per venture, latest build wins — for every build dated between 17 June and 24 July 2026.

Population387 build records (280 deployed, 107 escalated)
Window17 June – 24 July 2026
SourceLive production build telemetry, read from the pipeline's own stats route
UnitOne record per venture. Three cosmetic-revision records are excluded by the stats route itself
“Failed” meansOutcome escalated — the automated pipeline exhausted its attempt budget or hit a confident end-to-end verification failure, and routed the job to a human

What the numbers say

MeasureCountRate
Never reached a working, shipped state without a human107 of 38727.6%
Pulled up by a human before delivery (escalated + held)110 of 38728.4%
Flagged by automated QA at least once, then fixed and shipped92 of 38723.8%
Caught by QA or a human, combined199 of 38751.4%
Passed every gate untouched, first time188 of 38748.6%

Slightly more than half of all builds were caught by something before anyone saw them. Under half passed clean.

Which apps fail, and which don't

The failure rate is not evenly distributed. It is almost entirely a function of whether the app has a real backend.

WorkloadFailed unaidedRate
Data and scheduling apps (accounts, saved records, bookings)97 of 24839.1%
Static sites, games and simple tools8 of 1346.0%

A six-fold difference. If an app only has to render, AI builds it reliably. The moment it has to remember something, the failure rate goes up more than six times.

The single defect behind most failures

We classified the escalated builds by their recorded failure reason. One defect dominates everything else:

DefectShare of gate failures
The front end never calls the backend for its data87%
The primary action does nothing when clicked13%

Both are the same disease: the app looks finished and isn't wired. The scores bear that out — among failed attempts, code-weak-only outnumbered visual-weak-only by 37 to 2, and average visual quality (81.6) was indistinguishable from average code quality (80.8).

This matters because it is exactly what a non-technical owner reports: “it looks great but nothing saves”, “the button does nothing”. That is not a vague complaint. It is the most common failure mode in AI-assisted software, and it is mechanically detectable.

We are not alone in finding this. An independent scan of 5,600 live AI-built applications found 2,038 critical vulnerabilities.

Limitations — read these before quoting the number

  • This is our internal hardening corpus, not client work. These builds were run to find and fix weaknesses in our own pipeline. They are not a sample of customer projects.
  • The number is conservative — it makes us look worse than the pipeline does now. Escalations cluster heavily in the June stress-test batches (45 on 17 June alone). Only 4 escalations appear across the 41 dated July records, after our decomposition and lesson-mining fixes landed.
  • Operational contamination is included. Roughly 22 of the 107 escalations date to a single credit-exhaustion incident on 26 June. Excluding that day gives 85 of 365 — 23.3%. We report the higher figure because the noise cannot be cleanly separated.
  • 28.4% is a floor, not a ceiling. One record per venture means an escalated venture later re-run successfully overwrites to “deployed”, so human involvement is undercounted.
  • The combined QA-or-human figure is a range of 199–202 (51.4–52.2%) because of overlap ambiguity between holds and QA flags. We report the lower bound.
  • One number is deliberately withheld. Our end-to-end mission-verification pass rate is not published as a failure rate: it is advisory for some app types and structurally blind to canvas-based games, so it would not be a defensible public statistic.

What we changed because of it

The 87% finding is the reason our build gate now requires runtime proof that the front end actually reached the backend, rather than accepting that the code looks correct. A build that renders beautifully and saves nothing fails our gate before anyone sees it.

If you have an app in that state, the same detection runs as a code scan — it reads the app end to end and names every defect in plain English, whatever language or framework it was built in.

Citing this

Free to quote with attribution. Suggested form:

Launchr (2026). How often do AI-built apps fail? 387 builds, measured. Data collected 17 June – 24 July 2026. https://launchr.bot/research/ai-build-failure-rates/

If you want the underlying method in more detail than this page carries, ask us — we would rather the number was checked than repeated.