CHAPTERS
How big v0 is: adoption, deployments, and the rise of personal software
Aakash opens by asking for concrete traction metrics. Tom shares scale (millions of users) and emphasizes that v0 is enabling “personal software,” including for non-engineers.
- •~2M people have used v0 since launch
- •Over 2.5M deployments to Vercel from v0-built projects
- •v0 is not just for prototypes—people ship real apps
- •Tom’s focus: customer value and his own daily use cases
Live build #1: prompting a ‘better LinkedIn feed’ and using prompt enhancement
They begin a live demo by prompting for an improved LinkedIn newsfeed. Tom shows how v0 can expand a vague prompt into a structured plan resembling a lightweight PRD and then generate a multi-file app.
- •Using prompt enhancement to turn a simple idea into a detailed plan
- •v0 generates project structure, components, navigation, mock data
- •Watching the “plan” while code is authored in parallel
- •High iteration velocity: start broad, then refine
Live build #2: screenshot-to-prototype for a personalized Apollo-style SaaS homepage
Tom demonstrates using a screenshot as design input, cloning style and layout, then adapting it to a new use case (custom homepage based on which product module a user relies on). They discuss iterative vs. batch prompting styles.
- •Screenshot prompting for high-fidelity UI replication
- •Customizing a SaaS dashboard for meetings vs. email users
- •Atomic changes vs. multi-change prompts (like PRs)
- •Using v0 to quickly add nav and styling parity
Under the hood: multi-model approach and making generated code runnable
Aakash asks about model choice and competition-style settings. Tom explains v0’s ‘online model’ concept: orchestration across models plus post-processing to fix and iterate on code so it runs reliably.
- •v0 uses multiple models and additional system layers
- •Goal: hide complexity and provide a “happy path” UX
- •Large share of raw LLM code may not run without fixes
- •v0 iterates on returned code based on product knowledge
From prototypes to real apps: why high-fidelity demos change product workflows
They reflect on the value of near-instant prototypes for PMs and non-technical users. The core point is speed to demonstrate an idea with fidelity, enabling better feedback and faster decision-making.
- •Non-technical users can demo ideas quickly
- •High fidelity helps teams validate concepts faster
- •Prototyping changes how PMs and leaders collaborate
- •v0 can handle imperfect prompts and still converge
Debugging live: fixing missing routes and exploring generated app depth
Back in the LinkedIn clone, they click around, hit a missing route, and use v0 to diagnose and implement the missing page. This demonstrates interactive building: explore → encounter errors → ask v0 to fix.
- •Runtime error discovery via exploratory clicking
- •“Fix with v0” workflow for missing routes/pages
- •Iterative, conversational development style
- •Generated app includes notifications, composer, images, and more
Integrations demo: connecting providers (Groq) and handling API key failures
Tom introduces v0’s marketplace-style integrations and adds an AI provider integration live. They attempt an AI-assisted post composer, encounter API key and module errors, and show how v0 helps troubleshoot and roll back via restore.
- •One-click integrations from Vercel Marketplace
- •Adding AI features (Groq-powered post composer)
- •Common issues: invalid API key, missing exports, missing assets
- •Restore/versioning to roll back changes safely
What the CPO builds personally: changelog filter, e-commerce one-shot, and ‘where am I?’ app
Tom shares personal “small software” projects he built with v0: an Atom-feed UI for filtering posts, a one-shot sneaker store with real-time filters, and a simple neighborhood locator used weekly. The theme is empowered tinkering despite limited coding time.
- •Building internal tools quickly (Atom feed + filters)
- •One-shot e-commerce store with real-time filtering UX
- •Personal utility app: one-button neighborhood finder
- •“No more blank canvas”: start from existing patterns and iterate
Workflow and scaling path: browser-first creation, IDE export, and Git-style iteration
They discuss how users move from v0 to tools like Cursor/Windsurf and how Vercel wants tighter back-and-forth between editor and v0. Tom describes a future where changes map to commits/PR-like units and teams collaborate more seamlessly.
- •Export v0 code to any editor for deeper customization
- •Browser as a serious creation surface, not just consumption
- •Working toward round-trip syncing (editor ↔ v0)
- •Atomic changes framed like pull requests / Git commits
Database + deployment end-to-end: Neon integration, env vars, and shipping live to the internet
They add a Neon database to store upcoming meetings, generate schema + mock data, and wire the app to fetch from the DB. They handle environment variables and then deploy a project live, demonstrating real app shipping (not just mockups).
- •Neon database provisioning from within v0
- •Generating tables + mock records for the next month
- •Wiring UI to real DB data; creating forms for CRUD
- •Env var setup (NEON_DATABASE_URL) and redeploy
- •Deploying to a public vercel.app URL
Team + company building v0: a lean squad on top of Vercel’s infrastructure foundation
Aakash digs into how Vercel is staffed and how v0 ships quickly. Tom explains v0’s three pillars (models/research, chat fundamentals, and admin/billing) and how leveraging Vercel foundations (accounts, marketplace, deployments) keeps the team small.
- •v0 team is <14 people across eng/product/design
- •Three pillars: model/research, core chat UX, admin/periphery
- •Vercel overall EPD ~200 people
- •Foundation-first approach: reuse marketplace and deploy infra
How Vercel runs product: product areas, frequent reviews, and ‘lowercase-a agile’ (no rigid OKRs)
Tom outlines Vercel’s planning system: product areas with cross-functional leads owning roadmaps, light six-month resets, and frequent review meetings for kickoffs/execution/pre-ship. They use Notion + Linear with strong Slack integration, and avoid heavy OKR overhead.
- •12–15 product areas with cross-functional leads teams
- •Formal planning reset ~every 6 months, but frequent check-ins weekly
- •Review types: kickoff, execution check-in, pre-ship readiness
- •Tooling: Notion for planning/PRDs, Linear for execution, Slack cohesion
- •No formal OKRs; process was ‘overfit’ and slowed them down
Dogfooding v0: building v0 with v0, component-level generation, and demos over documents
They explore how the v0 team uses v0 internally: generating and iterating on small app pieces (like settings panels) and importing them into the main codebase. Tom argues prototypes complement PRDs, making PRDs thinner while demos validate hypotheses earlier (“seeing is believing”).
- •v0 used for component-level prototyping inside the v0 product itself
- •Iterate in v0 rather than only iterating in code
- •Internal uses extend beyond apps: slide decks and more
- •PRDs still matter for nuance/strategy, but can be thinner
- •Prototype demos surface edge cases and improve feedback quality
Strategy, competition, and the future: AI as the fabric; hybrid roles; advice for slower companies
Tom explains his competitive philosophy—focus on customer value rather than chasing competitors—then zooms out to how AI changes product work. He predicts more “design engineers” and “PM engineers,” urges leaders to start tinkering, and sees AI shifting from a button to an always-present capability in products and operations.
- •Competitive stance: don’t play catch-up; obsess over customer value
- •React’s ubiquity influences AI code generation defaults; frameworks become more of an implementation detail
- •Advice: start small, build conviction via tinkering; PM/design seats often face less tooling friction than engineering
- •AI won’t be an ‘AI button’—it becomes part of every roadmap
- •Future roles: increased overlap (design/PM/engineering) aided by AI assistants
