Stack Currency: a proposed benchmark axis for AI app builders (July 2026)
A neutral BuilderProof proposal to score AI app builders on Stack Currency across five documented sub-criteria. The finding: only v0 publicly version-stamps its generated stack in a dated changelog; three of five builders leave their framework foundation undocumented.
On this page
Quick answer
AI app builders generate real applications on real frameworks, yet almost none of them tell you which framework version you are getting, or what happens when they change it. This is a neutral BuilderProof proposal (July 2026) to add Stack Currency as a benchmark axis: how current, how supported, and how transparent each builder's generated stack actually is. We break it into five documented sub-criteria and map the current cohort against them. The headline finding is specific and neutral: only 
v0 publicly version-stamps its generated stack in a dated changelog, 
Lovable documents stack-level migrations, and the rest publish no primary source for the framework version they emit. This is a draft axis, open for community revision, and scores reflect what each vendor documents, not our opinion of quality.
Why stack currency deserves its own axis
BuilderProof already scores builders on how cleanly you can leave a platform (data-layer-portability-axis-proposal-july-2026) and how you recover from a bad change (rollback-safety-axis-proposal-july-2026). Stack Currency asks something earlier in the lifecycle: what are you standing on in the first place, and is it fresh?
The failure mode is quiet. An app scaffolded on an end-of-life framework or runtime major inherits security patches it will never receive and an upgrade cliff on day one. And because the builder, not the user, picks the scaffold, that choice is invisible unless the vendor publishes it. A builder can also change its default stack between two prompts months apart, so two users asking for "the same app" end up on structurally different foundations. For a community-editable benchmark, that reproducibility question is not academic: it decides whether a score from March still describes the product in July.
We priced this axis against the five platforms we could source primary documentation for: Lovable, 
Bolt.new, 
Replit, v0 by Vercel, and 
Base44.
The proposed axis: five sub-criteria
We score Stack Currency as five independent yes / partial / not-documented checks. A builder does not need all five; the point is to make the tradeoffs legible.
- Version-stamped output. The builder publicly states which framework and runtime version new apps are generated on (for example, "new apps use Next.js 16"), with a date.
- Actively-supported baseline. That documented stack sits on a currently-supported major version, not one past end-of-life. We measure "supported" against the upstream project's own release schedule, not our judgment.
- Migration transparency. When the builder changes its default stack, it announces the change with a date, so existing users know their new apps may diverge from their old ones.
- User-visible upgrade path. The user can see the versions in use and has a documented way to move them forward, rather than being pinned to whatever the model emits.
- Reproducible scaffold. The default scaffold (framework plus the core libraries wired in) is documented well enough that two users starting on the same day get the same baseline.
How the current cohort documents stack currency today
The matrix reflects each vendor's own published docs and changelogs as of July 2026. "Not documented" means we could not find a primary source, not that the behavior is absent. Corrections via /contribute are welcome and are how this benchmark stays honest.
Scroll to see more
| Builder | Version-stamped | Supported baseline | Migration transparency | Visible upgrade path | Reproducible scaffold |
|---|---|---|---|---|---|
| v0 | Documented | Documented | Documented | Documented | Documented |
| Lovable | Partial | Documented | Documented | Not documented | Partial |
| Bolt.new | Not documented | Not documented | Not documented | Not documented | Not documented |
| Replit | Not documented | Not documented | Not documented | Not documented | Not documented |
| Base44 | Not documented | Not documented | Not documented | Not documented | Not documented |
Reading the matrix
v0 is the outlier, and the only builder in the cohort that version-stamps its output in public, dated changelog entries. Vercel records that v0 moved to Next.js 16 for all new chats (v0 changelog, October 22, 2025), later pinned Next.js 16.2.0 and TailwindCSS 4.2.0 (v0 changelog, February 18, 2026), and now scaffolds new apps with Neon, Drizzle, and Better Auth by default (v0 changelog, June 8, 2026). Those are exactly the primary sources this axis rewards: a reader can tell what they are getting and when it changed.
Lovable documents its stack at the architecture level rather than the version level. Its changelog states that new apps created from May 13, 2026 use TanStack Start with server-side rendering by default, a switch away from the earlier React plus Vite scaffold (Lovable changelog, May 2026). That earns migration transparency and a supported baseline, but the exact pinned versions are not published, so version-stamped and reproducible-scaffold land at Partial. It is also a clean example of sub-criterion 3 mattering in practice: an app generated in April and one generated in June start from different frameworks.
Bolt.new, Replit, and Base44 each ship real, current stacks in practice, but we could not source a public, dated statement of the framework version their agents emit, nor a documented policy for changing it. That is the finding, not a verdict: three of five builders leave the single most load-bearing choice in a generated app, its foundation, undocumented. If any of these vendors publish version-stamping we missed, the /contribute link above corrects the row.
To keep "supported baseline" objective rather than editorial, we anchor it to the upstream projects' own end-of-life calendars, such as the Node.js release schedule, rather than to any ranking of our own.
What this axis is not
It is not a freshness race. Being first to a brand-new framework major is not automatically better; a builder that deliberately stays one major behind for stability can score well on "supported baseline" while being honest about it. The axis rewards documentation and support, not novelty. It also does not score the quality of the generated code, which lives on other axes.
Open for revision
Stack Currency is a draft. The obvious critique is that "documented" favors vendors with good changelog hygiene over vendors with good engineering, and that is a fair tension for a benchmark built on primary sources. If you maintain one of these platforms and can point to a version-stamping page we missed, or you want to argue the sub-criteria are wrong, the row and the rubric are both editable at /contribute.
Written by
BuilderProof editorial teamThe BuilderProof editorial team maintains the community-editable benchmark of AI app builders. We publish methodology proposals openly and score builders on documented behavior, not opinion.
Cite this benchmark
BuilderProof editorial team. "Stack Currency: a proposed benchmark axis for AI app builders (July 2026)". BuilderProof, July 2026. https://www.builderproof.org/benchmarks/stack-currency-axis-proposal-july-2026.
@misc{builderproof-stack-currency-axis-proposal-july-2026,
title = {{Stack Currency: a proposed benchmark axis for AI app builders (July 2026)}},
author = {{BuilderProof editorial team}},
year = {2026},
month = {jul},
howpublished = {\url{https://www.builderproof.org/benchmarks/stack-currency-axis-proposal-july-2026}},
note = {BuilderProof, builderproof.org}
}Frequently asked questions
What is stack currency for an AI app builder?
It is how current, how supported, and how transparent the framework and runtime that the builder generates your app on actually is. BuilderProof proposes scoring it across five documented sub-criteria: version-stamped output, an actively-supported baseline, migration transparency, a user-visible upgrade path, and a reproducible scaffold.
Which AI app builder documents its framework version most clearly?
As of July 2026, v0 by Vercel is the only builder in our cohort that version-stamps its output in a public, dated changelog, recording moves such as Next.js 16 for all new chats (October 22, 2025) and Next.js 16.2.0 with TailwindCSS 4.2.0 (February 18, 2026). Lovable documents stack-level migrations, such as new apps using TanStack Start from May 13, 2026, but not exact pinned versions.
Why does a silent stack migration matter?
Because the builder, not you, chooses the scaffold. When a builder changes its default stack between releases, two users who prompt for the same app months apart get structurally different foundations, which breaks reproducibility and can quietly move an app onto a framework you did not choose. That is why migration transparency is a scored sub-criterion.
Related benchmarks
Rollback Safety: a proposed benchmark axis for AI app builders (July 2026)
A neutral BuilderProof proposal to score AI app builders on Rollback Safety across five documented sub-criteria. The finding: code version history is now table stakes, but data-layer rollback is the sub-criterion almost none of them document.
Data-Layer Portability: A Proposed BuilderProof Axis for Whether You Can Take Your Database With You (July 2026)
Benchmarks measure whether you can leave an AI app builder with your code. Almost none measure whether you can leave with your data. A proposed sixth-family BuilderProof axis with a five-check rubric and preliminary, docs-based reads of five builders.
How We Benchmark AI App Builders: The BuilderProof Methodology v1
The BuilderProof methodology v1, dated June 19, 2026, in full: four axes, the OQ-7 test brief, environment standards, scoring weights, reproducibility steps, the operator disclosure, and the v2 open questions. This is the rubric that produces every June 2026 BuilderProof score.