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.
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 24 July 2026.
| Population | 387 build records (280 deployed, 107 escalated) |
|---|---|
| Window | 17 June – 24 July 2026 |
| Source | Live production build telemetry, read from the pipeline's own stats route |
| Unit | One record per venture. Three cosmetic-revision records 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 | 107 of 387 | 27.6% |
| Pulled up by a human before delivery (escalated + held) | 110 of 387 | 28.4% |
| Flagged by automated QA at least once, then fixed and shipped | 92 of 387 | 23.8% |
| Caught by QA or a human, combined | 199 of 387 | 51.4% |
| Passed every gate untouched, first time | 188 of 387 | 48.6% |
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) | 97 of 248 | 39.1% |
| Static sites, games and simple tools | 8 of 134 | 6.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.
We classified the escalated builds by their recorded failure reason. One defect dominates everything else:
| Defect | Share of gate failures |
|---|---|
| The front end never calls the backend for its data | 87% |
| The primary action does nothing when clicked | 13% |
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.
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.
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.