What v0 is genuinely for
v0 is a full-stack agentic builder built by Vercel. Since the February 2026 relaunch it has moved well past component generation: it imports GitHub repos, runs Git and PR workflows, executes a sandboxed Next.js runtime (API routes, Server Actions), runs commands in an agent terminal, and supports full MCP — custom servers, OAuth, usable both in-app and via the v0 API. The UI output is the highest-quality of any AI builder: screenshot or prompt to clean, responsive, accessible React/Next with Tailwind/shadcn, and one-click deploy to a Vercel project. It also self-tests the live preview using browser screenshots (May 2026) and auto-detects vulnerable React/Next versions.
For founders who need a polished screen quickly — a landing page, a dashboard layout, a form with real visual quality — v0 is a legitimate tool. We're not competing with it on UI quality or generation speed. We can't, and we don't try.
The question is what you do after the screen exists.
The gap generation leaves open
v0 generates code. It does not produce a record of where the code came from, which library version it depends on, or what happens to the component when a dependency changes.
It does not generate a test suite. The agentic preview self-checks the live output using browser screenshots, and it can detect and fix vulnerable React/Next versions — those are real checks. But they are not unit tests, integration tests, or a configurable CI runner. There is no test file in the repo after v0 is done. There is no "24 tests pass, 0 failed" line in the merge record.
It does not put a human name on the output. The component was generated. Nobody reviewed it in a technical-accountability sense. Nobody is reachable if the component breaks in production.
The gap is not a UI gap. The gap is: what checkable evidence exists that this component is safe to ship, and who signed off on it? From v0 today, the answer is: the live preview looked right. That is the primary signal.
The version problem
Generated code depends on libraries. Libraries change. The version your code was generated against and the version running in production will eventually diverge, and the divergence will happen silently.
v0 is reported — by community users and observed behavior, not by official documentation — to generate dependencies without explicit version pins, and to overwrite manually pinned versions on GitHub sync. The component references libraries, but the specific versions are whatever resolves at install time, not the specific combination the component was tested against.
When a library ships a breaking change, you find out when the component breaks in production. There is no pinned-version record to compare against. There is no trail that shows "this component was generated against react@18.3.1; the deployed version is now 18.4.0; here are the relevant changelog entries."
launch.ist pins every dependency. The provenance trail records the exact versions in use at generation time and re-checks on each dependency update. Drift is surfaced before it becomes a 2am incident.
Tests don't exist by default
v0 does not generate a test suite. The agentic preview uses browser screenshots to self-check the live output — that is a real verification step, and it catches rendering errors. It is not a test suite. No unit tests, no integration tests, no test files committed to the repo. It is not a configurable CI runner. The "tests pass" line does not exist in a v0 merge.
This is the predictable consequence of the generation model: the tool optimizes for producing output that looks correct right now. A test suite optimizes for proving output is correct after the next change, and the change after that, and the dependency update six months from now. These are different goals. Generation tools are built for the first. We are built for the second.
Our developer agent ships every function with tests. CI runs on every push. If they fail, the change doesn't merge. The test trail is part of the provenance record — "24 tests pass · 0 failed · 380 ms" appears in every signed merge. Not as a virtue signal. As a fact you can check.
Infrastructure stops at Vercel
v0 apps deploy to a standard Vercel project. Vercel is a real platform with real infrastructure: Fluid Compute functions on AWS, logs, function metrics, and a Drains export for SIEM. For many projects, it is a reasonable hosting choice. We're not arguing with that decision if you're already there.
The documented constraint is control and isolation. v0 apps run on shared Vercel infrastructure — not a dedicated or namespace-isolated environment. You do not control the cluster. On databases: Vercel's own Postgres and KV were discontinued in December 2024 (migrated to Neon and Upstash respectively); databases are now Marketplace-brokered, with Vercel Blob remaining first-party. There is no path to running your own Kubernetes namespace, your own observability stack, or your own CI/CD pipeline inside the v0 integrated workflow. Vercel's platform audit logs record team and security activity, and can export to a SIEM — but that is a platform event log, not an AI-generation provenance trail tying a code change to a source, a passing test, and a human reviewer.
For a landing page or a marketing site, Vercel is sufficient. For a production application where you need isolated infrastructure, control of the database layer, and an observability stack you own — you need more than a managed platform provides.
Every launch.ist project runs on isolated Kubernetes from day one. Your own namespace or dedicated cluster. Postgres, Valkey, MinIO, Grafana, TLS, backups. The DevOps agent provisions it. You bring your domain. From $59/month.
No one signs the work
v0 generates the component. Vercel deploys it. There is no step in this process where a human reviews the code, runs a verification pass, and puts their name on the merge.
This is not a criticism of Vercel's engineers — they built the tool. It is a description of what the tool's output model is: generation, then deployment, no accountability layer in between.
"Human signs the work" is not a compliance box. It is the mechanism by which someone is reachable when the component breaks in production at a scale that matters. It is the difference between "something went wrong" and "here's the diff, here's the trail, here's the engineer who reviewed it — ask them."
A named engineer reviews the agent's work, the provenance trail, and the verification results before anything merges. Their name is in the trail at /launches/<date>/<sha>. If something breaks later, the trail shows exactly what was checked and what state the codebase was in when the merge happened.
The provenance trail
A provenance trail is not a git log. A git log records what changed. A provenance trail records what was checked, what sources were cited, what versions were pinned, what tests passed, and who reviewed it — in a form you can re-run.
v0 produces no exportable provenance record for generated code. Vercel has platform audit logs (team and security activity, SIEM export) — that is a real capability. It is not an AI-generation provenance trail. The component exists, and the platform logged that it was deployed. How the code was generated, what it depends on at generation time, whether those dependencies are safe, whether the component passes your test suite — none of this is recorded in a form you can re-run or hand to an auditor.
Here is what a launch.ist provenance trail looks like for a single signed merge: cited at L18 against nextjs.org cookies() · 14.2 docs; verified at L20–22 against the OWASP cookies cheatsheet (2024-09); tested at L18–22 by session.spec.ts (4/4 pass); pinned to next@14.2.5 and iron-session@8.0.3. Trail archived at /launches/2026-05-14/2a91 — re-run any check months later.
This is what "merge-able" looks like with evidence behind it. The trail outlives the run. If a dependency ships a CVE six months from now, you can pull the original trail and compare.