v0

What v0 is

v0 is Vercel’s AI application builder. It turns instructions, visual references and existing code into interfaces and applications that can be reviewed, modified and deployed. Its scope includes both the visible interface and server connections and logic; it is more than a generator of screen images.

The useful distinction is between intention, implementation and an operational service. A request describes the desired outcome; code proposes how to achieve it; the service must demonstrate that it works with its actual data, users and conditions. v0 shortens the journey between these stages without making them equivalent. It can also modify an existing project, making the authorised scope of changes important.

Reference documentation: What is v0?.

Product history and development

Vercel announced v0’s transition from alpha to beta on 11 October 2023, initially focused on interfaces using React, Tailwind CSS and shadcn/ui. General availability followed in 2024, according to the provider’s retrospective.

On 11 August 2025, v0.dev became v0.app, alongside planning, research and debugging capabilities. A redesign focused on existing repositories and sandbox execution was presented on 3 February 2026. In March, the new.website team joined to develop tools and integrations. That announcement describes a product direction; it does not establish that every promised feature became available that day.

Reference documentation: Announcing v0: Generative UI · v0.dev becomes v0.app · Introducing the new v0 · new.website joins forces with v0.

How models, tools and execution work together

Vercel describes a process combining dynamic instructions, transformations during generation called LLM Suspense and automatic fixes. Its successful-generation metric refers to producing a website that renders in the preview. That is different from demonstrating that an application meets all its requirements correctly.

VM-backed chats use a sandbox with Node.js, files, commands and a development server. It is separate from production. This separation allows a change to be inspected before publication, but does not mean every connected external service is a test service. An isolated environment given broadly privileged credentials can still act on real resources.

Reference documentation: How we made v0 an effective coding agent · Sandbox.

Inputs and specifying behaviour

Files and screenshots can be supplied for v0 to analyse layout, colours and components. The documentation says it also infers functionality from visible elements. A screenshot shows one state, not an application’s complete rules.

A useful brief describes what each screen receives, what it returns and what happens when information is missing. For a filter, specify whether criteria combine, whether selection survives a language change and how no matches are displayed. For a form, identify required fields, errors and the submission destination. Asking for something “just like this picture” may address appearance while leaving the behaviour users need undefined.

Reference documentation: Screenshots and Files.

Visual design and reusable components

Design Systems 2.0 saves a design system as a skill that guides use of actual components, tokens and conventions. It can draw on packages, repositories, documentation and Figma references. The purpose is to reuse design rules rather than rely on each conversation remembering an appearance.

For a Sabentis project, the brief should specify corporate blue #2A62FE, authorised assets and component variants. Actual use then needs checking: contrast, visible focus, labels and behaviour with long text. Visual consistency cannot be validated from the opening screen alone; error screens and empty states are also part of the product.

Reference documentation: Design Systems 2.0.

Code, branches and reviewing changes

Once GitHub is connected, the repository becomes the code reference. v0 creates a working branch from the base branch and sends generated changes there. The workflow exposes differences, checks and pull requests before publication.

The team should read differences for a specific purpose: finding changes outside scope, removed resources and altered permissions. A styling fix should not introduce a new database without an explicit need. Keeping requirements and examples with the project helps explain why a change is accepted. History matters when several people work on the same product and a visual improvement affects existing functionality.

Reference documentation: GitHub.

Preview, publication and operation

Branch previews have their own URLs; publishing updates the production deployment and its stable address. In the documented GitHub workflow, publication merges the pull request into the base branch. Saving, reviewing and publishing are different states.

Before publishing, check the domain, visibility and environment connections. Afterwards, open the final URL and repeat essential actions: a successful build does not establish that public links, forms and permissions behave as intended. Decide who receives incidents, how an earlier version is restored and who maintains dependencies and content. The publish button ends a construction phase but begins an operational phase.

Reference documentation: Deployments · GitHub.

Data, APIs and MCP connections

v0 supports persistence through database and storage providers, documenting connections including Neon, Supabase, Upstash, Vercel Blob and Snowflake. For SQL integrations it can generate and execute operations that create, modify or delete tables. MCP adds tools from external servers and Marketplace services.

Classify each connection by what it permits, not just its service name. Reading a catalogue, editing it and sending information to third parties are different capabilities. For a prototype, fictitious data and restricted permissions allow the workflow to be tested without confusing it with an operational record. The input and output contract should cover errors and missing data as well as the successful path.

Reference documentation: Databases · MCP Integrations.

Web, iOS and programmatic access

Vercel described its iOS app in November 2025: it was built with React Native and Expo around conversation, without seeking complete parity with the website. The new API was announced as generally available on 5 August 2026, with chats maintaining application state and returning previews.

The API allows generation to become part of another product or process. This introduces responsibilities: associating requests with projects, retaining results and controlling deployment rights. An automated process should not interpret a new preview as an instruction to publish. For mobile work, reserve a larger-screen review when tables, code differences or multiple interface states need close inspection.

Reference documentation: How we built the v0 iOS app · Introducing the new v0 API.

Plans, models and usage costs

The reviewed documentation distinguishes Free, Plus, Business and Enterprise; it also retains Premium, which is being phased out and is closed to new users. Consumption depends on credits and generated work, not a fixed number of finished applications. Model selection depends on the plan and workspace settings; Enterprise adds owner controls for custom models.

An economic comparison should include generation, deployment and connected services. A builder subscription does not make storage, domains or every integrated API free. To estimate a project, measure a representative task including revisions, record consumption and separate initial construction from maintenance. Credit offers and limits change; check them in the account before committing to a work schedule.

Reference documentation: Pricing · Choosing models.

Data, code ownership and security

The AI policy effective in March 2026 ties training use to plans and preferences, excluding Enterprise customer data. Documentation distinguishes server secrets from NEXT_PUBLIC_ variables exposed to the browser. Vercel states that it does not claim ownership of generated code, although output may contain errors or resemble third-party material.

Ownership, privacy and security are therefore separate checks. Permission to use output does not establish that dependencies are properly licensed or that a form protects information. Before introducing internal material, verify effective team preferences and each connected provider’s scope. Secrets belong in configuration, not in instructions or public files.

Reference documentation: Vercel AI Policy · Security · FAQs.

Recognition and a provider security incident

v0 received the 2025 Webby award in Developer Tools. This recognises the product; it does not certify the security of applications generated with it.

On 19 April 2026, Vercel disclosed unauthorised access to internal systems involving a third party and environment variables belonging to a subset of customers. The updated bulletin states that remediation was completed and the incident closed on 16 October. It does not support a conclusion that all v0 applications were affected.

When choosing a tool, these facts support assessing both the product and its service chain. The practical criterion is knowing which credentials exist, who can revoke them and where relevant advisories are published. This profile does not attribute a security incident to the hypothetical project below.

Reference documentation: v0 from Vercel — Webby Winner 2025 · Vercel April 2026 security incident.

Applications in occupational safety and health

Sabentis proposes v0 as an aid to designing and developing interfaces for prevention content. These are use scenarios, not implementation results or risk assessment capabilities.

• Prevention library: explore cards, topics and languages so people can find the right document and identify its version. Currency information must come from the approved catalogue.
• Campaign: test the hierarchy between the main message, supporting resources and contact information. A prototype allows observation of whether the call to action is understandable on mobile and with a keyboard.
• Explaining indicators: create a demonstration with clearly fictitious data to review interpretation of filters, denominators and periods. The presentation should not resemble actual organisational results.

The contribution to OSH is reducing obstacles to understanding and finding information. An interface’s professional appearance does not make it a validated prevention tool. Technical content, permissions and updating criteria still need identifiable owners.

Hypothetical case: a resource library in three languages

A team wants to evaluate a public library with topic cards, a language selector and document links. A small catalogue contains title, language, topic, review date, URL and status. Withdrawn resources and examples are explicitly identified.

1. Define the task: find a particular resource in Spanish, Catalan and English. Specify that missing translations, dates and documents must not be invented.
2. Build the first version: request combinable filters, readable cards and an empty-results state. Keep public data separate from presentation.
3. Check edge cases: test a long title, a language without an equivalent resource, a withdrawn link and a search with no matches. Do not accept a language label changing while silently retaining a different document.
4. Evaluate access: check mobile and desktop, keyboard navigation, focus, labels and contrast. Ask someone to find the resource without showing them its location, recording difficulties.
5. Review the change: inspect code and differences, verify every link and decide which version meets publication criteria.

Acceptance requires each card to lead to its intended source, absences to be explained and the owner to be able to update the catalogue. If the prototype needs authentication or internal data, a new requirements and review phase begins. This case does not describe an executed user test or an already published service.

Limitations and quality criteria

An application can build successfully and fail its purpose: a form might confirm a submission that is never stored; an indicator might add incompatible values; a selector might change only a label. Testing needs to observe these consequences as well as appearance.

Sabentis proposes reviewing five dimensions: correct content, complete behaviour, accessibility, data handling and maintainability. Each needs concrete evidence. For example, reopening a record demonstrates persistence better than seeing a success message; navigating without a mouse reveals barriers a screenshot cannot show.

Successive changes can introduce regressions. Retaining a few representative cases helps verify that an improvement does not break previously accepted behaviour. The owner must be able to understand and maintain the project after the conversation; otherwise, initial speed can become operational dependence.

When to choose v0 and complementary tools

v0 is relevant when an interface idea needs to become reviewable code and there is capacity to maintain it. Figma can supply design references; GitHub Copilot can complement subsequent development. The choice depends on the remaining work: design, behaviour, integration or maintenance.

If communicating a static concept is sufficient, building an application may add unnecessary obligations. If the aim is to observe how a user filters, navigates or interprets information, an interactive prototype provides more useful evidence. Defining who reviews each aspect beforehand avoids accepting a version solely for its visual finish.

Frequently asked questions

Is a preview the published version?

No. A preview is for reviewing work; the production deployment serves the project’s stable address. Check which one is being shared.

Can a screenshot define an entire application?

No. Behaviour, permissions, data and alternative states must be supplied. What is invisible in the image can be decisive for the user.

Does generating code remove the need for development?

It reduces some initial writing, but architecture decisions, review, testing and maintenance remain. The ability to work with generated code is part of the selection criterion.