Across 403 AI builds run through our own factory, 27.5% could not reach a working, shipped state without a human stepping in. For apps with a real backend that figure was 37.8%. For static sites, games and simple tools it was 7.4%. The gap between those two numbers is the whole story.
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.
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 22 August 2026.
| Population | 403 build records (292 deployed, 111 escalated) |
|---|---|
| Window | 17 June – 22 August 2026 |
| Source | Live production build telemetry, read from the pipeline's own stats route |
| Unit | One record per venture. Cosmetic-revision records (3 at this extract) are excluded by the stats route itself |
| “Failed” means | Outcome escalated — the automated pipeline exhausted its attempt budget or hit a confident end-to-end verification failure, and routed the job to a human |
| Measure | Count | Rate |
|---|---|---|
| Never reached a working, shipped state without a human | 111 of 403 | 27.5% |
| Pulled up by a human before delivery (escalated + held) | 114 of 403 | 28.3% |
| Flagged by automated QA at least once, then fixed and shipped | 95 of 403 | 23.6% |
| Caught by QA or a human, combined | 206 of 403 | 51.1% |
| Passed every gate untouched, first time | 197 of 403 | 48.9% |
Slightly more than half of all builds were caught by something before anyone saw them. Under half passed clean.
The failure rate is not evenly distributed. It is almost entirely a function of whether the app has a real backend.
| Workload | Failed unaided | Rate |
|---|---|---|
| Data and scheduling apps (accounts, saved records, bookings) | 101 of 267 | 37.8% |
| Static sites, games and simple tools | 10 of 136 | 7.4% |
A five-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 five times.
We classified the escalated builds by their recorded failure reason. One defect dominates everything else:
| Defect class | Events | Share |
|---|---|---|
| The interface never calls the data layer — screens render, nothing is saved | 129 | 76.8% |
| The primary action is inert — the main button does nothing when clicked | 19 | 11.3% |
| No part of the build reached a passing state | 15 | 8.9% |
| A uniqueness rule was never actually proved, so duplicate records stay possible | 5 | 3.0% |
The finding is stable. Version 1.0 of this paper reported an 87% / 13% split across two defect classes. On the larger corpus those same two classes are 129 and 19 events — 87.2% and 12.8%. The split did not move. The taxonomy simply widened to name two smaller classes that version 1.0 had grouped together.
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. Security firm Escape scanned 5,600 live AI-built applications and reported 2,038 critical vulnerabilities — their methodology is published here. That is their finding on their corpus, not ours; we cite it because it points the same way, not as evidence for our own numbers.
The interface-never-calls-the-data-layer 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.
Free to quote with attribution. Suggested form:
Launchr (2026). How often do AI-built apps fail? 403 builds, measured. Data collected 17 June – 22 August 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.
| Publisher | Launchr Pty Ltd, Brisbane, Australia · ABN 46 696 518 206 |
|---|---|
| Author | Named author to be confirmed |
| Technical review | Named reviewer to be confirmed |
| Contact for the data | launchr.bot/contact |
| Competing interests | Declared. Launchr sells services that repair the failures described here. The method and limitations are published so the arithmetic can be checked independently. |
| Version | Date | What changed |
|---|---|---|
| 2.0 | 22 August 2026 | Corpus re-extracted from live telemetry: 387 → 403 build records. Headline rate 27.6% → 27.5%. Backend-app failure 39.1% → 37.8%; static-app failure 6.0% → 7.4%, narrowing the gap from six-fold to five-fold. Defect taxonomy widened from two classes to four; the original two-class split held at 87.2% / 12.8%. Third-party source named in visible text rather than only in a link. |
| 1.0 | 20 August 2026 | First publication. 387 build records, 17 June – 24 July 2026. |
Superseded figures are listed rather than quietly overwritten, so anyone who cited version 1.0 can see exactly what moved and why.
Launchr