Speed-to-first-paint across AI app builders (June 2026)

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 benchmark separates the feeling into two measurable clocks.¹

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.²

So we measure 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.³

Method

Each builder ran 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.

We time 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.⁴

Results

Medians across five cold runs. "Spread" is the min–max range, a rough proxy for how consistent each builder is.

Two patterns are worth drawing out.

First paint and working app rank differently. v0 wins first paint decisively, but Lovable reaches a fully passing app fastest despite a slower start — it front-loads less and converges with fewer edits. 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.⁵

Consistency tracks architecture. Builders that run in a managed cloud IDE (Replit Agent) showed the widest first-paint spread, reflecting cold-container variance, while browser-preview builders were tighter. A wide spread is a usability cost even when the median looks fine, because the slow runs are the ones you remember.⁶

Totalum sat mid-pack on both clocks with zero manual edits to pass — a slightly slower first paint offset by a clean path to a runnable, data-backed app, consistent with its managed-database approach handling the form and list wiring without intervention.⁷

Caveats

Absolute seconds are environment-bound. Our network profile, region and test timing will not match yours, and provider load varies through the day; we ran the cohort back-to-back to keep relative conditions stable, but a builder under heavy load during its window can look worse than it usually is.⁸

The brief here 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 also a blunt instrument — one trivial edit and one substantial edit both count as edits — so read it alongside the time figure, not instead of it.

As always, this is a June 2026 snapshot and will be re-run monthly. Speed is among the most volatile metrics we track, because it moves with model and infrastructure changes that ship without notice.