v0 by Vercel: What It Builds, Costs, and Still Needs Review

v0 can take a prompt to an editable, deployable web application, but a generated preview is not reviewed production software. Someone still has to verify what changed, where data travels, whether access controls hold, and how the application behaves when inputs, dependencies, or services fail.

This is a document-based workflow check using Vercel pages reviewed July 17, 2026. HUMAI did not sign in, import a repository, spend credits, generate code, download an output, publish a deployment, or test an application. Vercel's product descriptions establish documented capabilities, not independent findings about code quality, accessibility, security, speed, or commercial suitability.

v0 now describes a full-stack application workflow

If you remember v0.dev as a user-interface generator, the current scope is wider. The old addresses now lead to v0.app, where Vercel defines v0 as an AI agent for creating code, full-stack apps, and agents. Its documentation covers natural-language prompts, mockup input, backend connections, code changes, previews, pull requests, and Vercel deployment.

That breadth changes the evaluation. A visual prototype may need only realistic navigation and representative content. A working web application can also contain authentication, database queries, third-party APIs, environment variables, server routes, and payment or messaging integrations. Each added capability creates a review surface that the appearance of the preview cannot settle.

Write the handoff contract before the first prompt. Name the user journeys, data classes, integrations, browser support, performance budget, accessibility target, and functions that may remain simulated. Also name what v0 must not receive or change. Without that baseline, a later reviewer cannot tell whether an attractive addition is required scope, an unsafe assumption, or merely generated decoration.

The right question is therefore not whether v0 can display a plausible screen. It is whether your team can take responsibility for the resulting repository, services, data, costs, and deployment. Vercel's own AI Product Terms require users to evaluate output for correctness and appropriateness before using or sharing it. The same terms warn that output may be incomplete, contain bugs, or be unsuitable for the intended purpose.

The workflow has six human handoffs

Vercel's quickstart documents the prompt, preview, code, Design Mode, integration, and publish path. The current FAQ adds import from GitHub or a computer ZIP. None of those actions is an approval event. Each merely moves the application into a state where a different kind of evidence can be collected.

Keep the evidence at the same granularity as the change. A copy adjustment may need content and layout review. A new database call needs authorization, schema, privacy, retry, and failure checks. A changed authentication path needs a security owner. This prevents a conversationally small request from bypassing the larger review implied by the code it produces.

Preview and direct editing help inspection, not certification

Current previews run in Vercel Sandbox and can execute server-side code, API routes, database connections, and Development environment variables. That is more informative than a static mockup. It still does not reproduce every production condition, account permission, data volume, device, network failure, or third-party outage. A preview should be treated as one test environment, even when Vercel describes it as matching production behavior.

The browser code editor provides direct file editing, search, diff views, and split views. Design Mode can write visual changes back to source as another version. Those features make review possible, but they do not perform it. A reviewer still needs to connect a changed line to a requirement, inspect surrounding code, and check behavior beyond the visible screen.

For a prototype, define which interactions are intentionally fake and label them. For an application, replace placeholder paths with explicit acceptance tests. Include empty, loading, error, expired-session, unauthorized, rate-limited, slow-network, and partial-service states. Keep the prompt, resulting commit, test record, and reviewer together so a later change can be traced.

Use realistic structure without real sensitive records. Synthetic fixtures should include long names, missing values, duplicate submissions, unsupported file types, boundary dates, and hostile text where relevant. A happy-path preview populated with tidy sample data can conceal overflow, validation, encoding, and authorization failures that appear immediately in ordinary use.

Git and export create a review path, not automatic portability

GitHub connection is optional. When enabled, Vercel's documented Git workflow creates a dedicated branch for a chat, automatically commits code-changing messages, and moves changes toward the base branch through a pull request rather than pushing directly to main. That is a useful separation between generation and acceptance. An automatic commit still needs the same review as any other proposed change.

There is also an important custody rule. Once a repository is connected, the GitHub repository becomes the source of truth, and Vercel warns that deleting it may make the code unrecoverable. Confirm organization ownership, backup policy, branch protection, required reviewers, and recovery access before the repository becomes operationally important.

The FAQ says code can be exported and deployed elsewhere. Code portability does not imply environment portability. A v0 Project can share domains, deployments, integrations, and environment variables across chats. An exit packet should therefore include source and lockfiles, runtime versions, build commands, schemas and migrations, environment-variable names without secret values, external-service inventory, domain settings, and restore instructions.

Test that packet away from the originating workspace. A second authorized maintainer should be able to obtain the repository, install the pinned toolchain, configure fresh non-production credentials, run migrations, start the application, execute the test suite, and identify the release procedure from written instructions. If that handoff fails, export exists as a feature but independence has not been demonstrated.

Once the repository needs sustained local development, debugging, or multi-agent maintenance, the separate AI coding workspace guide covers that downstream decision. It is not a substitute for choosing or reviewing v0 here.

Production review covers six risks that the preview cannot close

• Accessibility: run keyboard-only navigation, focus-order, visible-focus, label, error-message, heading, contrast, zoom, reduced-motion, and screen-reader checks against agreed criteria. A polished layout is not an accessibility result.
• Security: review authentication and server-side authorization separately, trace every trust boundary, scan exposed bundles and logs for secrets, validate untrusted input, and test abusive requests. Vercel hosting does not approve application logic.
• Data flow: list every database, API, model, analytics tool, cookie, log, and storage location. Record retention, deletion, residency, and subprocessor decisions for the real configuration.
• Dependencies: reproduce installation from the lockfile, inventory packages and licenses, scan known vulnerabilities, identify abandoned components, and document why each runtime dependency is present.
• Tests: cover units, integrations, end-to-end journeys, authorization failures, migrations, concurrency, retries, and recovery. Keep results tied to a commit and environment rather than to a screenshot.
• Maintainability: check module boundaries, duplicated logic, types, error handling, configuration, observability, documentation, and ownership. A team must be able to modify the code without the original chat.

Integrations deserve a second contract check. Vercel documents routes from v0 to databases, storage, AI models, and external APIs in its full-stack guide. The AI Product Terms say non-Vercel services remain governed by their own terms and privacy notices. Approval for Vercel does not automatically approve a connected provider or the data sent to it.

Plans and credits need a dated checkout record

As displayed on the live pricing page on July 17, 2026, the new-customer routes are Free, Plus, Business, and Enterprise. Free shows $5 in monthly credits and a seven-message daily limit. Plus shows $30 per user each month, $30 in monthly credits per user, and $2 in daily credits on login. Business shows $100 per user each month with the same stated credit amounts and training opt-out by default. Enterprise uses custom pricing and lists role-based access control, SAML SSO, and a statement that data is not used for training.

A separate pricing documentation page still includes a $20 Premium plan, while marking it as being sunset and unavailable to new users. It explains that prompts, uploaded material, output, chat history, source files, and Vercel context contribute to token use. Model choice also changes the rate. A credit balance therefore cannot be translated into a reliable number of complete applications or messages.

The pricing documentation says unused monthly credits roll into the next billing cycle and expire after 65 days, while purchased Shared Credit Pool credits expire after one year. Vercel's AI Product Terms say credits expire one year after issue and do not roll over subsequent periods. The terms also say payments are final and generally non-refundable, subscriptions recur, and cancellation takes effect at the scheduled renewal date.

Those statements are not reconciled here. Before paying, capture the checkout page, plan name, seat count, included balance, purchased balance, expiry shown in the dashboard, auto-purchase setting, renewal date, tax treatment, cancellation path, and terms version. If the account display and legal text still differ, obtain written clarification rather than assuming the more favorable rule.

Estimate cost with a representative task packet, not a generation count from an older review. The packet should cover initial context, one routine revision, one larger corrective pass, and the review messages needed to inspect or fix the result. Record model, input and output use, added context, failed attempts, and the balance category charged. That is a reader-run budgeting method, not a HUMAI cost result.

Inputs, training controls, and output rights are separate decisions

The AI Product Terms define input broadly enough to include prompts, data, and attachments, and they prohibit sensitive personal information in input. Do not place real credentials, health information, financial account data, government identifiers, or unapproved customer records in a prompt, ZIP, screenshot, seed file, or imported repository. Vercel's Project documentation offers environment variables for credentials, but a reviewer must still confirm server-only use and prevent client exposure.

Vercel's FAQ says prompts or user content may be used with third-party models and learning systems to improve products. It also says Enterprise content, or content from a customer that has opted out in Vercel settings, is not used for training. The plan comparison marks data opt-out unavailable on Free and Plus, and available on Business and Enterprise. Check the control visible in the intended workspace and the applicable agreement; do not infer an opt-out from a general account setting.

The FAQ documents downloads of user-generated prompts or content and a contact route for deleting v0 output. It also warns that deleting inputs or outputs does not update models that were already trained with them. Public output, chats, community templates, or code can be viewed and copied by others under the AI Product Terms, so visibility is part of the pre-upload decision.

Commercial use is not settled by the phrase "you own the code." The terms say that, as between the customer and Vercel and where law permits, the customer owns Customer Content and receives any Vercel rights in output. They also say output may be non-unique and that the assignment does not cover third-party rights or another user's output. Review input rights, package and asset licenses, trademarks, copied interface elements, and output provenance for the actual project before commercial release.

The ship or stop gate

1. Scope: the accepted requirements, deliberately mocked functions, supported browsers, data classes, and release owner are written down.
2. Repository: a clean checkout builds from locked dependencies, the complete diff has named reviewers, and recovery does not depend on one chat or account.
3. Behavior: acceptance, accessibility, authorization, failure, migration, and recovery tests pass against the exact release commit.
4. Data: every external transfer, secret, retention rule, deletion path, production log, and third-party agreement has an accountable owner.
5. Rights: inputs are authorized and code, packages, fonts, images, copy, and interface elements have project-specific clearance.
6. Operations: production configuration, monitoring, alerting, rollback, backup restoration, incident response, and maintenance ownership are rehearsed or documented.
7. Billing: plan, credits, expiry, renewal, auto-purchase, seat access, training control, and cancellation evidence match the workspace that will ship.

Ship only when every gate has retained evidence and a named approver. Stop when a live preview is the only proof, a secret or sensitive record may have entered input, the repository cannot be rebuilt independently, a critical test is missing, commercial rights remain assumed, or the billing and training settings cannot be confirmed.