Screenshot-to-React benchmark
This benchmark measures whether a tool can turn the same visual reference and requirements into a React application that looks right, behaves correctly, survives edits, and runs outside the builder.
The short answer
Use fixed inputs, three viewports, a shared acceptance script, a controlled edit, a recovery test, and a clean-room export. Publish every artifact needed to reproduce the score.
At a glance
100-point benchmark rubric
Score every category from 0 to its maximum and attach direct evidence for each deduction.
| Category | Points | Full-credit standard |
|---|---|---|
| Desktop visual fidelity | 15 | Hierarchy, spacing, typography, color, imagery, and detail match |
| Responsive inference | 15 | Intentional phone and tablet composition without overflow |
| Semantic structure | 10 | Meaningful HTML and maintainable component boundaries |
| Interaction completeness | 15 | Core tasks work with loading, error, and success feedback |
| Accessibility | 10 | Named controls, keyboard path, focus, headings, and contrast |
| Edit containment | 10 | Bounded changes preserve unrelated files and behavior |
| Recovery | 10 | Known-good version restores predictably without history loss |
| Export readiness | 10 | Clean install, build, start, routes, and assets outside preview |
| Usage transparency | 5 | Cost before and after the accepted outcome can be explained |
A fair test
Compare the complete workflow
Use the same inputs and acceptance criteria, then evaluate the path from first request to a locally runnable artifact.
- 01
Prepare
Normalize the prompt, screenshot, product requirements, target framework, viewports, and tasks.
- 02
Generate
Run from a clean project and record settings, time, usage, and interventions.
- 03
Score
Apply the rubric at all viewports and complete the interaction script.
- 04
Stress
Perform the controlled edits and recovery scenario.
- 05
Export
Build and run the artifact in a clean environment, then publish the evidence package.
Test protocol
Use the same account tier where possible, start from a new project, provide the same prompt and reference, prohibit manual code edits before initial scoring, and stop the first phase only when the product claims the generation is complete.
Viewport protocol
Capture the source desktop width plus a 390px phone and a 768px tablet or small laptop. Score both fidelity to known evidence and the quality of inferred responsive behavior.
Interaction protocol
Define five to ten concrete tasks from the reference: navigation, menu state, forms, filters, tabs, dialogs, or primary calls to action. Test keyboard access and visible feedback as part of the same task.
Controlled edit protocol
Request one bounded visual change and one bounded behavior change. Diff every generated file and subtract points for unrelated copy, styling, component, or state changes.
Recovery protocol
Introduce a reproducible regression, locate the last good version, restore it using the native product workflow, and confirm both the UI and project history remain coherent.
Export protocol
Download or sync the project into a clean environment, install with the documented package manager, run type checking and linting if configured, build for production, and repeat the core interaction script.
Evidence package
Publish the reference image, exact prompt, settings, timestamps, usage screenshots, desktop and mobile captures, generated source, edit diff, recovery recording, export inventory, and local build log.
Decision evidence
What to verify before choosing
Use primary documentation and your own exported artifacts. Product capabilities and pricing change too quickly for memory-based comparisons.
0 points
Missing or unusable
The requirement is absent, broken, or cannot be evaluated from the supplied artifact.
1/3 credit
Recognizable but fragile
The direction is visible, but important details, states, or widths fail.
2/3 credit
Functional with clear gaps
The requirement works but has material fidelity, quality, or maintainability issues.
Full credit
Production-credible
The result meets the documented acceptance standard with reproducible evidence.
FAQ
Frequently asked questions
Direct answers to the questions buyers and builders ask before committing a project to an AI app builder.
Is this benchmark affiliated with Lovable, Bolt, or v0?
No. It is a Squid-authored methodology designed to make cross-tool evaluation more reproducible. Product capabilities should be verified against current official documentation.
Why is visual fidelity only 15 points?
The benchmark separates desktop resemblance from responsive behavior, accessibility, interactions, edit stability, recovery, and export. Together, design quality still represents a large share of the score.
Can I change the category weights?
Yes. Publish your weights before running the tools and explain why they match your product risk. Do not change them after seeing results.
How many runs should I perform?
Use at least three independent runs per tool for directional conclusions. Report the median and the range because model output is non-deterministic.
Does a local build prove production readiness?
No. It is a minimum portability check. Security, performance, browser coverage, data migration, observability, and operational review still remain.
Keep researching
Related guides and comparisons
Build an app you can inspect, restore, and keep.
See the expected model cost before generation, review the resulting files, and export a verified React project when it is ready.