Speed-to-first-paint across AI app builders (June 2026)
The BuilderProof speed protocol uses two stopwatches rather than one number: speed-to-first-paint (prompt to first rendered preview frame) and time-to-working-app (prompt to all acceptance checks passing with zero manual edits), across five cold runs on a fixed network profile. The June 2026 timing table was placeholder data and was withdrawn on August 21, 2026.
Updated on August 24, 2026
On this page
The timing table originally published on this page has been withdrawn. Our own reference list described those figures as "v0.1 preview figures" pending a public dataset, and the independently reproduced cycle promised for July 2026 was never run. Placeholder numbers should not have been presented as measured medians, and BuilderProof does not retain the per-run timing logs that would let a reader reproduce them. The two-clock protocol below is unchanged and remains the published method. See methodology v1.1 for the current evidence basis.
This page defines the BuilderProof speed protocol: two separate stopwatches rather than one "speed" number. Speed-to-first-paint is wall-clock from prompt submission to the first rendered preview frame. Time-to-working-app is wall-clock from prompt submission until the brief's acceptance checks all pass with zero manual edits. The protocol calls for five cold runs per builder on a fixed network profile, reporting the median and the min to max spread. The June 2026 timing table has been withdrawn, so this page currently documents method only and ranks no builder.
Speed is the metric people feel before they can articulate it. A builder that shows a working preview in ten seconds feels categorically different from one that takes a minute, even when the slower tool produces better code. This protocol separates the feeling into two measurable clocks.1
Background
"Fast" is ambiguous. There is the speed at which a builder shows you something, a first paint that tells you it understood the prompt, and the speed at which it gives you something you can actually ship. These are different quantities, and conflating them produces misleading leaderboards.2
So the protocol measures both. Speed-to-first-paint rewards responsiveness and is what most demos implicitly show off. Time-to-working-app rewards getting to a correct, runnable result and is what actually governs how much of your afternoon a builder consumes. The two often disagree, and the disagreement is the interesting part.3
The protocol
Each builder runs the same lightweight brief, a two-page app with one form and one list view, five times from a cold session, on a fixed network profile, with no warm cache.
Two stopwatches per run. Speed-to-first-paint: wall-clock from prompt submission to the first rendered preview frame. Time-to-working-app: wall-clock from prompt submission until the brief's acceptance checks all pass with zero manual edits. Five cold runs per builder; report the median and the min to max spread. Identical network profile across builders to remove bandwidth as a variable.
The protocol times the production-equivalent path, not a cached or pre-warmed demo state. Cold runs are harsher and noisier, but they reflect the experience of actually starting a new project rather than re-rendering one the platform already has in memory.4
Results
The timing table that stood here from June 9, 2026 to August 21, 2026 reported medians and min to max spreads to the second. Figures at that precision are a claim about specific runs on specific hardware, and BuilderProof cannot produce those runs. They have been removed rather than restated with hedging language, because hedged placeholder timings are still placeholder timings.
Nothing on this page currently ranks any builder against any other.
What still holds without the numbers
Two points survive the withdrawal, because they are properties of the measurement design rather than results.
The two clocks can rank a field differently. A builder that paints early is not necessarily the one that reaches a passing app first, and a single blended "speed" score hides exactly that. If your workflow is "show a client something in the meeting", first paint matters most. If it is "get to a deployable result", the second clock is the one to watch.5
Spread is a result, not noise to be averaged away. A wide min to max range is a usability cost even when the median looks fine, because the slow runs are the ones you remember. Any speed benchmark that publishes a median without a spread is withholding half the finding.6
Caveats
Absolute seconds are environment-bound in any case. Network profile, region and test timing differ between any two operators, and provider load varies through the day, so a builder under heavy load during its window can look worse than it usually is.8
The brief is intentionally small, to isolate startup latency from generation volume. A larger brief widens every number and can reorder the field, because builders that stream output incrementally feel faster on big tasks than their first-paint number suggests. "Manual edits to pass" is a blunt instrument, since one trivial edit and one substantial edit both count as edits, so it is read alongside the time figure rather than instead of it.
Speed is among the most volatile things this lab tracks, because it moves with model and infrastructure changes that ship without notice. Any future timing carries a run date and is read against that date.
Publication date correction, August 24, 2026
A date audit run on August 24, 2026 found that the publication timestamp stored for this page predated the registration of builderproof.org, so the recorded date cannot be the date on which this page was published. The stamp was an artifact of the launch content import rather than a real publication date, and no publication log survives that would let the true one be recovered. The timestamp has been corrected to the earliest date consistent with the evidence that does survive. The benchmark text, the protocol and the August 21, 2026 withdrawal notice at the top of this page are unchanged.
References
- BuilderProof editorial team. (2026). Speed protocol v2: two-clock timing. BuilderProof Methodology. builderproof.org/methodology#speed
- BuilderProof. (2025). Why a single "speed" number misleads. BuilderProof Notes.
- BuilderProof. (2026). Scoring model and weighting. builderproof.org/methodology#scoring
- Google Chrome team. (2026). Core Web Vitals (web.dev). Reference for the user-perceived loading metrics that frame the first-paint discussion.
- BuilderProof. (2026). Retraction notice: speed v0.1 preview figures withdrawn August 21, 2026. BuilderProof Methodology.
- BuilderProof editorial team. (2026). Variance is a usability cost: the runs you remember. BuilderProof Notes.
- BuilderProof. (2026). Builders we track. builderproof.org/builders
- BuilderProof. (2026). Versioning and re-test policy. builderproof.org/methodology#versioning
- v0 by Vercel. (2026). v0 product page. Vendor reference for a builder tracked on this axis.
- Lovable. (2026). Lovable product page. Vendor reference for a builder tracked on this axis.
Written by
BuilderProof editorial teamPublished by the BuilderProof editorial team - the maintainers of the public, versioned benchmark methodology.
Cite this benchmark
BuilderProof editorial team. "Speed-to-first-paint across AI app builders (June 2026)". BuilderProof, June 2026. https://www.builderproof.org/benchmarks/speed-to-first-paint-ai-app-builders-june-2026.
@misc{builderproof-speed-to-first-paint-ai-app-builders-june-2026,
title = {{Speed-to-first-paint across AI app builders (June 2026)}},
author = {{BuilderProof editorial team}},
year = {2026},
month = {jun},
howpublished = {\url{https://www.builderproof.org/benchmarks/speed-to-first-paint-ai-app-builders-june-2026}},
note = {BuilderProof, builderproof.org}
}Frequently asked questions
What is the difference between the two clocks?
Speed-to-first-paint is wall-clock from prompt submission to the first rendered preview frame; it measures responsiveness. Time-to-working-app is wall-clock from prompt submission until the brief's acceptance checks all pass with zero manual edits. The two often disagree, and the disagreement is the interesting part.
Why were the June 2026 timings withdrawn?
Because they were placeholder figures, described in this page's own reference list as "v0.1 preview figures" pending a public dataset, and the independently reproduced cycle promised for July 2026 was never run. Medians and spreads quoted to the second are a claim about specific runs, and BuilderProof cannot produce those runs, so the table was removed on August 21, 2026.
Does this page rank any builder?
No. As of August 21, 2026 this page documents the two-clock protocol only. No builder is timed, ranked or compared here.
Why report the median of five runs?
Because a single cold run is noisy. Cold-container variance, model warm-up and back-end queue load all push individual runs around. The median of five is a more stable point estimate than a single sample, and the protocol also reports the min to max spread so a reader sees consistency, not just the headline number.
Would I see the same seconds anyway?
Probably not exactly. Absolute seconds depend on network profile, region, time of day and provider load. Relative ordering under a fixed cohort-wide profile is what a speed benchmark can compare; treat any median as a same-network ordering rather than a wall-clock contract.
How are manual edits counted?
Coarsely. One trivial edit and one substantial edit both register as one edit; the figure is a directional signal, not a credit-hour count. It is read alongside the time-to-working-app figure, not instead of it.