Lovable vs v0

Agent access

1. ai-native userPoint an agent at llms.txt or agent-oriented docs

   weight 2 · round to Lovable
   Lovable✓fullprobed9/10

   Direct probe evidence confirms Lovable serves an llms.txt file at docs.lovable.dev/llms.txt with a 200 response and structured summary content, directly satisfying the story of pointing an agent at agent-oriented docs; docs also show broader agent-friendly integrations (MCP server, custom MCP, API) reinforcing agenticness. Missing for 10: no independent/community corroboration that external agents actually consume this llms.txt successfully.

   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.lovable.dev/llms.txt # Lovable Documentation > Lovable Documentation — Build full-stack websites w…”
   • [claimed-docs] “your AI agent can create projects, send messages to Lovable, inspect code, deploy apps, and more, all without leaving the client you're alre…”
   • [claimed-docs] “Lovable can read from it as live context while you build: internal CRMs, private APIs, company knowledge bases, or niche third-party tools.”

   proof ↗⚑ flag

   v0—none0/10

   No evidence that v0 publishes an llms.txt file or agent-oriented docs endpoint that other agents can be pointed at; the docs.md probe shows a markdown version of a page but not a standardized llms.txt/agent-discovery mechanism referenced anywhere in the pack.

   ⚑ flag

2. ai-native userRun the product headlessly / in CI for automation

   weight 2 · round to v0
   Lovable~partialclaimed3/10

   Lovable exposes an MCP server that lets external AI agents create projects, send messages, inspect code, and deploy programmatically, and a 'Build with URL' API for pre-filled prompts, which could enable some automated/programmatic triggering — but there is no documentation of a CLI, headless run mode, or CI/pipeline integration for automated builds. missing for 10: CLI/headless execution mode, explicit CI pipeline support, documentation of non-interactive automated runs.

   • [claimed-docs] “your AI agent can create projects, send messages to Lovable, inspect code, deploy apps, and more, all without leaving the client you're alre…”
   • [claimed-docs] “The Lovable API Build with URL feature lets you create links that open Lovable with a prompt already written, and optionally with reference …”
   • [claimed-docs] “Turn a published Lovable app into an MCP server for ChatGPT, Claude, and other AI assistants. Configure tools, sign-in, permissions, and acc…”

   proof ↗⚑ flag

   v0~partialclaimed5/10

   v0 provides a programmatic API/SDK (v0-sdk) allowing chat/code-gen calls to be scripted, and GitHub integration runs CI checks and can auto-fix CI failures, suggesting some automation-friendly hooks; but there's no documented headless CLI mode or explicit CI-runner integration pattern (e.g., GitHub Actions example) for orchestrating v0 itself within a pipeline. missing for 10: a documented CLI/headless mode, an official CI/CD pipeline example (e.g., GitHub Actions), and independent confirmation of running v0 fully unattended in automation.

   • [claimed-docs] “The v0 API gives you programmatic access to all of v0's capabilities, letting you integrate v0's AI-powered code generation, chat interface,…”
   • [github] “const response = await v0.chats.create({ message: 'Build me a personal website', })”
   • [github] “Set V0_API_KEY, or deploy server-side code on Vercel with OIDC enabled, then use the default client.”
   • [claimed-docs] “Connect a v0 project to GitHub to keep its code in a repository, work on isolated branches, preview changes, run CI, and publish through pul…”
   • [claimed-docs] “CI checks: See whether checks are running, passing, skipped, or failing.”
   • [claimed-docs] “v0 reads the relevant logs, diagnoses the failure, and applies a fix.”

   proof ↗⚑ flag

3. ai-native userPlug MCP servers into this product so it can use their tools

   weight 3 · round to Lovable
   Lovable✓fullclaimed8/10

   Lovable explicitly supports plugging in MCP servers via custom MCP connectors and MCP registries, letting the app 'read from it as live context' from internal CRMs, private APIs, or third-party tools, and lets members pick servers from a registry to connect as chat connectors. missing for 10: independent/hands-on verification of connecting a third-party MCP server and using its tools in a live build, and more detail on tool invocation mechanics.

   • [claimed-docs] “Lovable can read from it as live context while you build: internal CRMs, private APIs, company knowledge bases, or niche third-party tools.”
   • [claimed-docs] “members then pick servers from it and connect them as chat connectors in a couple of clicks, instead of finding and pasting each server's UR…”
   • [claimed-docs] “the ClickHouse app + chat connector lets your Lovable app run SQL queries against your ClickHouse database over the HTTP interface”
   • [claimed-docs] “You get everything in the web app plus local MCP server support, multi-project tabs, and keyboard shortcuts.”

   proof ↗⚑ flag

   v0—none0/10

   No evidence that v0 supports connecting to MCP servers or consuming their tools; docs mention integrations with databases, backend services, and AI providers but never reference MCP. missing for 10: any mention of MCP protocol/server support, documented tool-use via MCP, or third-party MCP connector.

   ⚑ flag

4. ai-native userUse an official CLI

   weight 2 · round drawn
   Lovable—none0/10

   The evidence pack covers Lovable's web app, desktop app, mobile app, MCP server integrations, Git sync, and API-based URL building, but no official CLI tool is mentioned anywhere in the docs or community evidence.

   ⚑ flag

   v0—none0/10

   Evidence shows a v0 API and a JavaScript/TypeScript SDK (v0-sdk) for programmatic access, but no official command-line interface tool is documented anywhere in the pack.

   • [claimed-docs] “The v0 API gives you programmatic access to all of v0's capabilities, letting you integrate v0's AI-powered code generation, chat interface,…”
   • [github] “const response = await v0.chats.create({ message: 'Build me a personal website', })”
   • [github] “Set V0_API_KEY, or deploy server-side code on Vercel with OIDC enabled, then use the default client.”

   proof ↗⚑ flag

5. ai-native userDrive the product through a documented public API

   weight 3 · round drawn
   Lovable✓fullprobed8/10

   Lovable documents an official MCP server that lets an AI agent create projects, send messages, inspect code, and deploy apps entirely programmatically without leaving the agent's client, which is precisely a documented public interface for AI-native control; there's also a 'Build with URL' API for prompt-driven project creation. Missing for 10: a traditional REST/OpenAPI spec (probe confirms no openapi.json found) and independent third-party corroboration of agents actually driving Lovable via this API.

   • [claimed-docs] “your AI agent can create projects, send messages to Lovable, inspect code, deploy apps, and more, all without leaving the client you're alre…”
   • [claimed-docs] “The Lovable API Build with URL feature lets you create links that open Lovable with a prompt already written, and optionally with reference …”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.lovable.dev/openapi.json, https://docs.lovable.dev/swagger.json, https://docs.lovable.d…”

   proof ↗⚑ flag

   v0✓fullclaimed8/10

   v0 documents a full public API (v0.app/docs/api/platform) offering programmatic access to code generation, chat, project management, and deployment, backed by an official SDK (vercel/v0-sdk) with concrete code examples (chats.create, streaming reads, API key/OIDC auth). This is corroborated by GitHub SDK evidence, not just marketing docs. Missing for 10: independent third-party developer reports/tutorials building production integrations on the API, and more detail on API rate limits/versioning.

   • [claimed-docs] “The v0 API gives you programmatic access to all of v0's capabilities, letting you integrate v0's AI-powered code generation, chat interface,…”
   • [claimed-docs] “Custom chat interfaces - Build your own UI for v0's AI-powered code generation”
   • [claimed-docs] “Start with existing files (fast, no tokens)”
   • [claimed-docs] “GitHub integration for repository imports”
   • [claimed-docs] “Export capabilities for backup and migration”
   • [github] “const response = await v0.chats.create({ message: 'Build me a personal website', })”
   • [github] “const result = readV0Stream(serverResult.toResponse())”
   • [github] “Set V0_API_KEY, or deploy server-side code on Vercel with OIDC enabled, then use the default client.”

   proof ↗⚑ flag

6. ai-native userIssue scoped/least-privilege API credentials for an agent

   weight 2 · round to Lovable
   Lovable~partialclaimed4/10

   Lovable lets you turn a published app into an MCP server and 'configure tools, sign-in, permissions, and access' for the AI assistants that connect, and enterprise plans add 'granular access controls' and centralized identity — both gesture at scoping what an agent can do. However, there's no documented mechanism for issuing discrete, least-privilege API keys/tokens (e.g., scoped, expiring, revocable credentials) specifically for an agent to use Lovable's own APIs. Missing for 10: explicit scoped/short-lived API credential issuance, per-agent token management, revocation/audit workflow tied to individual credentials.

   • [claimed-docs] “Turn a published Lovable app into an MCP server for ChatGPT, Claude, and other AI assistants. Configure tools, sign-in, permissions, and acc…”
   • [claimed-docs] “Turn a published Lovable app into an MCP server for ChatGPT, Claude, and other AI assistants.”
   • [claimed-docs] “centralized identity, granular access controls, workspace-wide security oversight, scheduled Deep scans, audit logs, regional code hosting”

   proof ↗⚑ flag

   v0—none0/10

   Evidence shows only a single API key (V0_API_KEY) or OIDC-based server auth for the v0 SDK, with no mention of scoped, role-based, or least-privilege credential issuance for agents. Missing for 10: any documentation of granular permission scopes, per-agent tokens, or restricted API key capabilities.

   • [github] “Set V0_API_KEY, or deploy server-side code on Vercel with OIDC enabled, then use the default client.”
   • [claimed-docs] “Securely store sensitive information like API keys, tokens, and other credentials.”

   proof ↗⚑ flag

7. ai-native userBuild against official SDKs

   weight 2 · round to v0
   Lovable—none0/10

   Lovable documents an MCP server integration and a lightweight 'Build with URL' API for triggering prompts, but there is no evidence of an official SDK (e.g., Python/JS client libraries) for developers to build against, and probes for an OpenAPI/swagger spec all returned 404s. missing for 10: dedicated SDK packages/docs, published API reference, and independent confirmation of programmatic SDK usage.

   • [claimed-docs] “The Lovable API Build with URL feature lets you create links that open Lovable with a prompt already written, and optionally with reference …”
   • [claimed-docs] “your AI agent can create projects, send messages to Lovable, inspect code, deploy apps, and more, all without leaving the client you're alre…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.lovable.dev/openapi.json, https://docs.lovable.dev/swagger.json, https://docs.lovable.d…”

   proof ↗⚑ flag

   v0✓fullclaimed7/10

   v0 provides an official v0-sdk on GitHub with documented API usage (v0.chats.create, streaming, API key auth) plus a Platform API documented for programmatic access to chat, code generation, and project management. missing for 10: independent/hands-on developer corroboration of SDK reliability, multi-language SDK support, and deeper API reference coverage beyond quickstart snippets.

   • [github] “const response = await v0.chats.create({ message: 'Build me a personal website', })”
   • [github] “const result = readV0Stream(serverResult.toResponse())”
   • [github] “Set V0_API_KEY, or deploy server-side code on Vercel with OIDC enabled, then use the default client.”
   • [claimed-docs] “The v0 API gives you programmatic access to all of v0's capabilities, letting you integrate v0's AI-powered code generation, chat interface,…”
   • [claimed-docs] “Custom chat interfaces - Build your own UI for v0's AI-powered code generation”

   proof ↗⚑ flag

8. ai-native userSubscribe to events via webhooks

   weight 2 · round drawn
   Lovable—none0/10

   Lovable's docs describe it acting as an MCP client/server, database/backend features, and integrations (GitHub, Slack, ClickHouse), but there is no evidence of a webhook subscription mechanism for external systems to receive events from Lovable projects or the platform itself.

   ⚑ flag

   v0—none0/10

   No evidence of a webhooks subscription/event system in v0's docs or API pack; the API is described as request/response (create chats, streaming) with no mention of webhook endpoints or event subscriptions.

   ⚑ flag

Agentic features

1. ai-native userGet AI-generated insights and suggestions from my data inside the product

   weight 2 · round to v0
   Lovable—none0/10

   Lovable's docs describe database creation, SQL querying, and AI connectors for building AI features into apps, but there is no evidence that Lovable itself analyzes a user's data and proactively surfaces AI-generated insights or suggestions inside the product experience.

   • [claimed-docs] “For direct database access, use the SQL editor at Cloud tab → SQL editor”
   • [claimed-docs] “For direct database access, use the SQL editor at **Cloud tab → SQL editor**”
   • [claimed-docs] “Lovable's built-in AI connector handles that setup for you, so you can add AI features to your app by describing what you want to build.”
   • [claimed-docs] “Describe the data your app needs in chat, and Lovable creates the tables and schema for you.”

   proof ↗⚑ flag

   v0~partialclaimed4/10

   v0 offers some AI-driven analysis of a user's own data in the sense of reading logs, diagnosing build failures, and applying fixes, and it 'plans, creates tasks, and connects to databases as it builds,' which is a narrow form of AI-generated insight/suggestion from data within the product. However, there is no evidence of broader data-insight features (e.g., analytics, trend/insight surfacing from business or usage data) beyond code/log diagnostics, and no independent corroboration of this specific capability. Missing for 10: dedicated data-insight/analytics features, independent hands-on evidence of 'insights' beyond build-error fixing.

   • [claimed-docs] “v0 reads the relevant logs, diagnoses the failure, and applies a fix.”
   • [claimed-docs] “Automatically fix errors in your code with intelligent diagnostics.”
   • [claimed-docs] “select Fix with v0 or Fix Build. v0 reads the relevant logs, diagnoses the failure, and applies a fix.”
   • [claimed-docs] “v0 plans, creates tasks, and connects to databases as it builds.”

   proof ↗⚑ flag

2. ai-native userSet up automations that run autonomously in the background

   weight 2 · round drawn
   Lovable—none0/10

   Lovable's Build/Agent mode executes tasks end-to-end but only when explicitly invoked by a user prompt (docs-4, docs-29, docs-30), not as a background/scheduled automation. The only autonomous background action found is enterprise 'scheduled Deep scans' for security auditing (docs-46), which is a narrow compliance feature, not a general-purpose automation/scheduling capability for building autonomous background workflows.

   • [claimed-docs] “Build mode (previously Agent mode) is Lovable's autonomous execution mode, designed to implement changes directly in your project. When you …”
   • [claimed-docs] “Build mode (previously Agent mode) is Lovable’s autonomous execution mode, designed to implement changes directly in your project. When you …”
   • [claimed-docs] “Lovable working on a request doesn't block you. Send a follow-up, a correction, or a new idea at any time to steer the work”
   • [claimed-docs] “centralized identity, granular access controls, workspace-wide security oversight, scheduled Deep scans, audit logs, regional code hosting”

   proof ↗⚑ flag

   v0—none0/10

   v0's docs describe on-demand code generation, GitHub integration, deployments, and API access, but there is no evidence of scheduled/triggered automations or background agentic tasks that run autonomously without a user-initiated chat or API call (e.g., no cron jobs, webhooks, or persistent background workers are described). The closest features (auto-fix on CI failure, 'Fix with v0') are triggered by user action or CI events within a user-initiated flow, not autonomous background automation.

   • [claimed-docs] “v0 reads the relevant logs, diagnoses the failure, and applies a fix.”
   • [claimed-docs] “select Fix with v0 or Fix Build. v0 reads the relevant logs, diagnoses the failure, and applies a fix.”
   • [claimed-docs] “open the branch menu and select Fix Conflicts, Fix CI, or Fix CI + Conflicts.”
   • [claimed-docs] “v0 plans, creates tasks, and connects to databases as it builds.”

   proof ↗⚑ flag

3. ai-native userDelegate tasks to a built-in AI assistant inside the product

   weight 3 · round drawn
   Lovable✓fullcommunity8/10

   Lovable's core interaction model is a chat-based AI assistant with an explicit 'Build mode' (formerly Agent mode) described as an autonomous execution mode that takes ownership of tasks end-to-end, applies changes via diffs, and lets users issue follow-ups asynchronously while it works. Community use (PM prototyping, internal dashboards) corroborates people actually delegating build tasks to it via chat, and docs show it can also perform actions like publish/deploy from chat commands. Missing for 10: independent benchmark or hands-on validation of the autonomy claims (e.g., how well it handles complex multi-step tasks unattended) and a clearer sense of failure/success rate limits.

   • [claimed-docs] “Build mode (previously Agent mode) is Lovable's autonomous execution mode, designed to implement changes directly in your project. When you …”
   • [claimed-docs] “Build mode (previously Agent mode) is Lovable's autonomous execution mode, designed to implement changes directly in your project.”
   • [claimed-docs] “Build mode (previously Agent mode) is Lovable’s autonomous execution mode, designed to implement changes directly in your project. When you …”
   • [claimed-docs] “Lovable working on a request doesn't block you. Send a follow-up, a correction, or a new idea at any time to steer the work”
   • [claimed-docs] “Lovable applies changes directly to your project when using Build mode. All modifications are visible through file diffs and summaries.”
   • [claimed-docs] “you describe what you want in the chat panel on the left, and you watch your app take shape in the preview on the right”
   • [claimed-docs] “you can also ask Lovable to run project actions from chat, for example publish my app, deploy this project, ship it, or find me a domain for…”
   • [claimed-docs] “Ask Lovable to publish, deploy, ship, or go live, and it handles the deploy for you while respecting all publish-related workspace settings …”
   • [community] “"I'm using Lovable heavily for PM prototyping and it's great. I think, if anything, current subscription may be too cheap!"”
   • [community] “Startup CTO uses Lovable heavily for internal dashboards/CRUD tools; saved the equivalent of two full-time developers, but generated code is…”

   proof ↗⚑ flag

   v0✓fullprobed8/10

   v0 is itself a built-in AI assistant that users delegate coding/build tasks to: docs show it plans, creates tasks, connects to databases, diagnoses and fixes build/CI errors autonomously (v0-docs-35, v0-docs-9/17/20, v0-docs-26), and community reports confirm a full 'dev-to-deploy' delegation experience with an MVP built end-to-end (v0-comm-1). Missing for 10: independent benchmarking of autonomous task delegation beyond anecdote, and no detail on multi-step task planning transparency.

   • [claimed-docs] “v0 plans, creates tasks, and connects to databases as it builds.”
   • [claimed-docs] “v0 reads the relevant logs, diagnoses the failure, and applies a fix.”
   • [claimed-docs] “Automatically fix errors in your code with intelligent diagnostics.”
   • [claimed-docs] “select Fix with v0 or Fix Build. v0 reads the relevant logs, diagnoses the failure, and applies a fix.”
   • [claimed-docs] “open the branch menu and select Fix Conflicts, Fix CI, or Fix CI + Conflicts.”
   • [community] “Built a feature-rich internal app (time tracker w/ auth, roles, export) and had a working MVP in users' hands by Monday. 'The speed was incr…”
   • [probe] “PROBE docs-md: HTTP 200 at https://v0.app/docs.md --- title: What is v0? description: v0 is an AI agent that helps anyone create real code a…”

   proof ↗⚑ flag

4. ai-native userOperate the product with natural-language commands

   weight 2 · round to Lovable
   Lovable✓fullcommunity9/10

   Lovable's entire interaction model is natural-language: users describe apps, request auth, database schemas, publishing, and even run project actions ('publish my app', 'deploy this project') directly from chat, with the agent taking ownership of execution end to end. This is corroborated across docs (chat panel, Build mode, database/auth generation) and independent usage reports confirming real prototyping via prompts, though quality of generated output is debated. Missing for 10: no independent benchmark of command breadth/reliability beyond anecdotal community reports.

   • [claimed-docs] “You describe what you want to build, and Lovable generates a working application that includes frontend, backend, database, authentication, …”
   • [claimed-docs] “Build mode (previously Agent mode) is Lovable's autonomous execution mode, designed to implement changes directly in your project. When you …”
   • [claimed-docs] “Build mode (previously Agent mode) is Lovable’s autonomous execution mode, designed to implement changes directly in your project. When you …”
   • [claimed-docs] “Describe the data your app needs in chat, and Lovable creates the tables and schema for you.”
   • [claimed-docs] “you describe what you want in the chat panel on the left, and you watch your app take shape in the preview on the right”
   • [claimed-docs] “you can also ask Lovable to run project actions from chat, for example publish my app, deploy this project, ship it, or find me a domain for…”
   • [claimed-docs] “Ask Lovable to publish, deploy, ship, or go live, and it handles the deploy for you while respecting all publish-related workspace settings …”
   • [community] “"I'm using Lovable heavily for PM prototyping and it's great. I think, if anything, current subscription may be too cheap!"”
   • [community] “Startup CTO uses Lovable heavily for internal dashboards/CRUD tools; saved the equivalent of two full-time developers, but generated code is…”

   proof ↗⚑ flag

   v0✓fullprobed8/10

   v0's core interaction model is natural-language chat: docs and SDK show building apps from prompts like 'Build me a personal website', plus NL-driven fixes, migrations, and mockup-to-UI conversion, and community reports confirm fast prompt-to-deploy workflows in practice. Missing for 10: independent evidence on breadth/reliability of more complex multi-step NL commands and any documented failure modes for ambiguous instructions.

   • [claimed-docs] “Create custom hooks and functionality”
   • [claimed-docs] “Turn mockups into real, high-fidelity user interfaces that reflect user flows and constraints.”
   • [claimed-docs] “v0 reads the relevant logs, diagnoses the failure, and applies a fix.”
   • [claimed-docs] “Quickly scaffold full-stack apps or components following best practices and modern standards.”
   • [claimed-docs] “Migrate to the latest Next.js features”
   • [claimed-docs] “Automatically fix errors in your code with intelligent diagnostics.”
   • [claimed-docs] “v0 plans, creates tasks, and connects to databases as it builds.”
   • [github] “const response = await v0.chats.create({ message: 'Build me a personal website', })”
   • [community] “Built a feature-rich internal app (time tracker w/ auth, roles, export) and had a working MVP in users' hands by Monday. 'The speed was incr…”
   • [probe] “PROBE docs-md: HTTP 200 at https://v0.app/docs.md --- title: What is v0? description: v0 is an AI agent that helps anyone create real code a…”

   proof ↗⚑ flag

Api quality

1. ai-native userDownload a machine-readable API spec (OpenAPI or equivalent)

   weight 2 · round drawn
   Lovable—none0/10

   Lovable is an app-building platform, not an API-first product, but a machine-readable API spec is still a fair ask for AI-native consumption of its own API/MCP surface; the probe explicitly found all OpenAPI candidate paths returning 404, and no docs mention an OpenAPI or equivalent machine-readable spec being downloadable.

   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.lovable.dev/openapi.json, https://docs.lovable.dev/swagger.json, https://docs.lovable.d…”

   proof ↗⚑ flag

   v0—none0/10

   v0 documents a REST-like API platform and SDK (v0-docs-4, v0-gh-1) but no evidence anywhere shows a downloadable OpenAPI/Swagger spec or other machine-readable API description; missing for 10: OpenAPI/JSON schema file, published spec endpoint, or SDK auto-generation from spec.

   • [claimed-docs] “The v0 API gives you programmatic access to all of v0's capabilities, letting you integrate v0's AI-powered code generation, chat interface,…”
   • [github] “const response = await v0.chats.create({ message: 'Build me a personal website', })”
   • [github] “Set V0_API_KEY, or deploy server-side code on Vercel with OIDC enabled, then use the default client.”

   proof ↗⚑ flag

2. ai-native userTest against a sandbox environment without touching production data

   weight 1 · round to v0
   Lovable~partialclaimed4/10

   Lovable offers workarounds like GitHub branch testing outside production (lovable-docs-14/20) and 'drafts' as separate copies with independent chat/preview (lovable-docs-34), which can approximate sandboxed testing, but there is no explicit built-in staging/sandbox database or environment separation from production data in the Cloud backend docs. missing for 10: dedicated staging/sandbox database environment, explicit dev/prod data isolation in Cloud backend, first-party documentation of a sandbox testing mode.

   • [claimed-docs] “you can export and sync your project to GitHub: back up your code, review changes in pull requests, work locally in your IDE, test features …”
   • [claimed-docs] “back up your code, review changes in pull requests, work locally in your IDE, test features on branches, and deploy outside Lovable”
   • [claimed-docs] “When several people build in the same project, each of you can work in your own draft: a separate copy of the project with its own chat and …”
   • [claimed-docs] “Lovable hosts your app and includes a built-in backend (Cloud) with database, authentication, storage, edge functions, and AI, no infrastruc…”

   proof ↗⚑ flag

   v0~partialclaimed6/10

   v0 supports isolated branches and preview deployments that are separate from the production URL, letting changes be reviewed/tested before they affect production (v0-docs-38, v0-docs-39, v0-docs-29, v0-docs-11). However, there is no explicit sandbox/staging environment for data (e.g., a separate database or mock data layer) — integrations like Supabase/Neon/Upstash appear to connect directly to real backend services rather than a sandboxed copy. Missing for 10: explicit data-isolation/sandbox environment separate from production databases, first-party documentation of a test/staging data layer, and independent confirmation that production data is never touched during preview/testing.

   • [claimed-docs] “Preview deployments are built from working branches.”
   • [claimed-docs] “work on isolated branches, preview changes, run CI, and publish through pull requests”
   • [claimed-docs] “When multiple chats share a Project, deploying from any of them updates the same production URL.”
   • [claimed-docs] “One Project shares deployment, hosting, domains, and environment variables for the chats connected to it.”
   • [claimed-docs] “Available integrations include databases like Upstash for Redis and Neon for Serverless Postgres, backend services like Supabase, and AI mod…”

   proof ↗⚑ flag

3. ai-native userRely on versioned APIs with a documented deprecation policy

   weight 2 · round drawn
   Lovable—none0/10

   No evidence of a versioned API or a documented deprecation policy; probe for OpenAPI spec returned 404 on all candidate paths, and docs mention a 'Lovable API' for build-with-url links only without versioning/deprecation info.

   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.lovable.dev/openapi.json, https://docs.lovable.dev/swagger.json, https://docs.lovable.d…”
   • [claimed-docs] “The Lovable API Build with URL feature lets you create links that open Lovable with a prompt already written, and optionally with reference …”

   proof ↗⚑ flag

   v0—none0/10

   While v0 documents an API platform (v0-docs-4, v0-docs-19) and an SDK (v0-gh-1..3), there is no evidence of API versioning scheme or a documented deprecation policy anywhere in the evidence pack.

   ⚑ flag

1. ai-native userPerform bulk operations across many items at once

   weight 2 · round drawn
   Lovable—none0/10

   The evidence pack describes app-building, database schema creation, and SQL editor access, but nothing about performing bulk operations across many items (e.g., batch editing records, bulk API calls, mass content operations) as a distinct AI-native capability. No feature, doc, or community report addresses bulk operations at scale.

   ⚑ flag

   v0—none0/10

   The evidence shows v0's API can programmatically create individual chats/projects, but there is no documentation or example of performing bulk/batch operations across many items at once (e.g., batch generation, bulk edits, mass deployment). Nothing in the docs or SDK references batching, looping over collections, or multi-item transactions.

   ⚑ flag

2. ai-native userSchedule recurring jobs or workflows

   weight 2 · round drawn
   Lovable—none0/10

   No evidence of any scheduling, cron, or recurring-workflow capability in Lovable's docs; the product focuses on chat-driven app generation, edge functions, and one-off deploys with no mention of scheduled/recurring job execution.

   ⚑ flag

   v0—none0/10

   No evidence anywhere in the pack of scheduling, cron-like triggers, or recurring workflow automation in v0; the product is oriented around chat-driven code generation, deployment, and API-triggered chats, not scheduled/recurring jobs.

   ⚑ flag

3. ai-native userVersion, review, and roll back my automations

   weight 1 · round to v0
   Lovable~partialclaimed5/10

   Lovable supports Git sync/export to GitHub or GitLab enabling version control, PR review, and branch-based testing (lovable-docs-14, lovable-docs-20, lovable-docs-33), and the Telegram bot integration mentions checking 'edit history' (lovable-docs-51). However, this is framed around app/code versioning, not specifically 'automations' as a distinct artifact, and there's no dedicated in-app rollback UI, automation-specific version history, or diff-based rollback mechanism described beyond Git-based workflows. missing for 10: native in-app rollback/version history UI independent of Git, explicit automation-specific versioning (vs. general app code), and independent/hands-on confirmation that rollback works reliably in practice.

   • [claimed-docs] “you can export and sync your project to GitHub: back up your code, review changes in pull requests, work locally in your IDE, test features …”
   • [claimed-docs] “back up your code, review changes in pull requests, work locally in your IDE, test features on branches, and deploy outside Lovable”
   • [claimed-docs] “Git sync connects a Lovable project to a repository you own on GitHub or GitLab, and keeps the two in sync automatically”
   • [claimed-docs] “Check edit history and review what changed... Query your project database with read-only queries”
   • [claimed-docs] “Work locally in your IDE. Clone the repository, edit and commit locally, and push. Your changes sync back into Lovable.”

   proof ↗⚑ flag

   v0~partialclaimed6/10

   v0's GitHub integration gives git-based version control (isolated branches, commits, PRs, CI checks) which supports versioning and review of generated projects, and branch/PR mechanics implicitly allow reverting to prior states. However, there is no explicit 'rollback' feature or chat/version history UI documented specifically for automations, and 'automations' as a distinct concept (vs. generated code) isn't addressed. Missing for 10: dedicated rollback/undo capability, explicit versioning of automations (not just code), and independent evidence of review/rollback workflows in practice.

   • [claimed-docs] “Connect a v0 project to GitHub to keep its code in a repository, work on isolated branches, preview changes, run CI, and publish through pul…”
   • [claimed-docs] “The Duplicate Branch dialog creates a new chat and branch containing the current branch's commits.”
   • [claimed-docs] “open the branch menu and select Fix Conflicts, Fix CI, or Fix CI + Conflicts.”
   • [claimed-docs] “CI checks: See whether checks are running, passing, skipped, or failing.”
   • [claimed-docs] “work on isolated branches, preview changes, run CI, and publish through pull requests”

   proof ↗⚑ flag

Ai features

1. ai-native userAdd AI features like LLM calls and agents to my generated app without managing provider keys myself

   weight 2 · round to Lovable
   Lovable✓fullclaimed8/10

   Lovable's docs explicitly describe a built-in AI connector that handles LLM/agent setup so users can add AI features by describing them, without managing provider keys, as part of the built-in Cloud backend (database, auth, storage, edge functions, AI). Missing for 10: independent/hands-on verification of the AI connector's provider-key management and details on supported models/providers.

   • [claimed-docs] “Lovable's built-in AI connector handles that setup for you, so you can add AI features to your app by describing what you want to build.”
   • [claimed-docs] “Lovable hosts your app and includes a built-in backend (Cloud) with database, authentication, storage, edge functions, and AI, no infrastruc…”
   • [claimed-docs] “Lovable hosts your app and includes a built-in backend (Cloud) with a database, storage, authentication, realtime, and functions.”

   proof ↗⚑ flag

   v0~partialclaimed5/10

   v0's project integrations explicitly include 'AI model providers' alongside databases like Upstash and Neon, and v0 can securely store API keys/tokens for connected services, suggesting some ability to wire in LLM/agent providers without manual key wrangling in code — but v0-docs-44 implies the user still supplies and stores the provider key themselves rather than v0 fully abstracting key management, and there's no dedicated doc on built-in LLM/agent calling with zero-config provider access. missing for 10: explicit documentation of a first-party managed LLM/agent provider (no user-supplied key required), hands-on confirmation that AI features work without configuring provider credentials.

   • [claimed-docs] “Available integrations include databases like Upstash for Redis and Neon for Serverless Postgres, backend services like Supabase, and AI mod…”
   • [claimed-docs] “Available integrations include databases like Upstash for Redis and Neon for Serverless Postgres, backend services like Supabase”
   • [claimed-docs] “Securely store sensitive information like API keys, tokens, and other credentials.”
   • [claimed-docs] “v0 plans, creates tasks, and connects to databases as it builds.”

   proof ↗⚑ flag

Auth

1. developerAdd user sign-up and login (email, social providers) scaffolded by the builder

   weight 3 · round to Lovable
   Lovable✓fullclaimed9/10

   Docs explicitly describe generating signup/login pages wired to the backend with row-level security, and managing sign-in via email, phone, Google, Apple, Microsoft, and SAML SSO through the built-in Cloud backend (Supabase-based). This directly matches the story of scaffolding auth with email and social providers via the builder. Missing for 10: independent hands-on confirmation that social provider login actually works end-to-end (community evidence focuses on other aspects like performance/security disclaimers, not auth scaffolding specifically).

   • [claimed-docs] “Ask Lovable to add login, and it generates the signup and login pages, wires them to your backend, and protects user data with row level sec…”
   • [claimed-docs] “Ask Lovable to add login, and it generates the signup and login pages, wires them to your backend, and protects user data with row level sec…”
   • [claimed-docs] “Manage your app's users and configure how they sign in: email, phone, Google, Apple, Microsoft, and SAML SSO, all part of the built-in backe…”
   • [claimed-docs] “Lovable hosts your app and includes a built-in backend (Cloud) with database, authentication, storage, edge functions, and AI, no infrastruc…”
   • [claimed-docs] “The built-in backend utilizes Supabase's open-source foundation, which means you get a production-ready environment from day one, without ne…”

   proof ↗⚑ flag

   v0~partialcommunity5/10

   v0 integrates with backend services like Supabase (which typically provide auth) and one community report describes building an app 'with auth, roles' using v0, suggesting the builder can scaffold authentication flows. However, there is no first-party documentation specifically describing sign-up/login scaffolding, social provider integration, or auth templates. Missing for 10: explicit docs on email/social auth scaffolding, named auth provider integrations (e.g., Auth.js, Clerk), and independent verification of social login flows.

   • [community] “Built a feature-rich internal app (time tracker w/ auth, roles, export) and had a working MVP in users' hands by Monday. 'The speed was incr…”
   • [claimed-docs] “Available integrations include databases like Upstash for Redis and Neon for Serverless Postgres, backend services like Supabase, and AI mod…”
   • [claimed-docs] “Available integrations include databases like Upstash for Redis and Neon for Serverless Postgres, backend services like Supabase”
   • [claimed-docs] “Connect to backend to build rich, data driven applications.”

   proof ↗⚑ flag

Database

1. developerGet a database provisioned and wired into my app without leaving the builder

   weight 3 · round to Lovable
   Lovable✓fullclaimed8/10

   Lovable's built-in Cloud backend provisions a database automatically as part of app generation, lets users describe data in chat to create tables/schema, and exposes a SQL editor for direct access, all without leaving the builder; it's built on Supabase's foundation so no separate setup is needed. missing for 10: independent/hands-on confirmation specifically validating the database provisioning flow (community evidence discusses other pain points, not this one).

   • [claimed-docs] “Lovable hosts your app and includes a built-in backend (Cloud) with database, authentication, storage, edge functions, and AI, no infrastruc…”
   • [claimed-docs] “Lovable hosts your app and includes a built-in backend (Cloud) with a database, storage, authentication, realtime, and functions.”
   • [claimed-docs] “Describe the data your app needs in chat, and Lovable creates the tables and schema for you.”
   • [claimed-docs] “For direct database access, use the SQL editor at **Cloud tab → SQL editor**”
   • [claimed-docs] “The built-in backend utilizes Supabase's open-source foundation, which means you get a production-ready environment from day one, without ne…”

   proof ↗⚑ flag

   v0✓fullclaimed7/10

   v0's Project docs explicitly describe connecting databases (Neon Postgres, Upstash Redis) and backend services (Supabase) directly within a Project, with v0 stated to 'plan, create tasks, and connect to databases as it builds,' and secrets/env vars are managed within the same Project without leaving the tool. This matches the story of provisioning and wiring a database inline in the builder. Missing for 10: no independent/hands-on report confirming the actual provisioning flow works smoothly, and no detail on whether v0 auto-creates the database instance or just connects an existing one.

   • [claimed-docs] “Available integrations include databases like Upstash for Redis and Neon for Serverless Postgres, backend services like Supabase, and AI mod…”
   • [claimed-docs] “Available integrations include databases like Upstash for Redis and Neon for Serverless Postgres, backend services like Supabase”
   • [claimed-docs] “Connect your project to third-party services to give your Project access to external data and functionality.”
   • [claimed-docs] “Connect to backend to build rich, data driven applications.”
   • [claimed-docs] “v0 plans, creates tasks, and connects to databases as it builds.”
   • [claimed-docs] “Securely store sensitive information like API keys, tokens, and other credentials.”

   proof ↗⚑ flag

Security

1. developerHave the platform review my generated app for security issues before it goes live

   weight 2 · round to Lovable
   Lovable✓fullcommunity7/10

   Lovable ships built-in Basic and Deep security scanners specifically for reviewing generated apps for vulnerabilities, with enterprise tiers adding scheduled Deep scans and audit logs, directly matching the pre-launch security review story. Missing for 10: independent/hands-on verification that the scanners catch real vulnerabilities, and community commentary (disclaimer requiring users to take responsibility for security, reports of abandoned apps with exposed data) raises doubt about how effective the review is in practice.

   • [claimed-docs] “Lovable includes two built-in security scanners, Basic scan and Deep scan, plus optional connectors for additional coverage.”
   • [claimed-docs] “Lovable includes two built-in security scanners, Basic scan and Deep scan, plus optional connectors for additional coverage”
   • [claimed-docs] “Lovable includes two built-in security scanners, **Basic scan** and **Deep scan**, plus optional connectors for additional coverage.”
   • [claimed-docs] “Lovable provides two built-in security scanners: Basic scan and Deep scan.”
   • [claimed-docs] “centralized identity, granular access controls, workspace-wide security oversight, scheduled Deep scans, audit logs, regional code hosting”
   • [community] “Signed up for Lovable, picked a template, got a disclaimer to 'take responsibility over project security, compliance, data, operations' with…”
   • [community] “"Lovable is marketed to non developers, so their core users wouldn't understand a security flow if it flashed red... Several were made on lo…”

   proof ↗⚑ flag

   v0—none0/10

   No evidence pack item mentions any security review, vulnerability scanning, or pre-launch security audit feature; deployment features focus on CI/build fixes and hosting, not security review. Missing for 10: any documented security scanning/review capability, evidence of vulnerability detection, or pre-deploy security checklist.

   ⚑ flag

Server logic

1. developerAdd server-side functions and third-party integrations like payments and email from the builder

   weight 2 · round to Lovable
   Lovable~partialclaimed6/10

   Lovable's built-in Cloud backend explicitly includes edge/serverless functions and supports connecting third-party services via chat connectors, custom MCP servers, and an AI connector (lovable-docs-27, -31, -40, -41, -44), and Build mode lets developers add these directly from the builder chat (lovable-docs-4, -29). However, no evidence specifically documents built-in payments or email-sending integrations (e.g., Stripe, Resend/SendGrid) — missing for 10: explicit payments integration docs, explicit transactional email integration docs, and independent confirmation these work end-to-end.

   • [claimed-docs] “Lovable hosts your app and includes a built-in backend (Cloud) with database, authentication, storage, edge functions, and AI, no infrastruc…”
   • [claimed-docs] “Lovable hosts your app and includes a built-in backend (Cloud) with a database, storage, authentication, realtime, and functions.”
   • [claimed-docs] “Lovable's built-in AI connector handles that setup for you, so you can add AI features to your app by describing what you want to build.”
   • [claimed-docs] “Lovable can read from it as live context while you build: internal CRMs, private APIs, company knowledge bases, or niche third-party tools.”
   • [claimed-docs] “the ClickHouse app + chat connector lets your Lovable app run SQL queries against your ClickHouse database over the HTTP interface”
   • [claimed-docs] “Build mode (previously Agent mode) is Lovable's autonomous execution mode, designed to implement changes directly in your project. When you …”

   proof ↗⚑ flag

   v0~partialclaimed5/10

   v0 docs show clear support for connecting projects to backend services and third-party integrations (Supabase, Upstash Redis, Neon Postgres, AI providers) and securely storing API keys/credentials, plus a general 'third-party services for external data and functionality' hook, which covers server-side function-like backend connections. However, no evidence specifically confirms out-of-the-box payments (e.g., Stripe) or email (e.g., Resend/SendGrid) integrations, nor detailed docs on writing custom server-side functions beyond generic 'connect to backend' language. Missing for 10: explicit payment-provider integration examples, explicit email-service integration examples, and documentation of custom server-side function authoring within the builder.

   • [claimed-docs] “Connect to backend to build rich, data driven applications.”
   • [claimed-docs] “Available integrations include databases like Upstash for Redis and Neon for Serverless Postgres, backend services like Supabase, and AI mod…”
   • [claimed-docs] “Connect your project to third-party services to give your Project access to external data and functionality.”
   • [claimed-docs] “Available integrations include databases like Upstash for Redis and Neon for Serverless Postgres, backend services like Supabase”
   • [claimed-docs] “Securely store sensitive information like API keys, tokens, and other credentials.”

   proof ↗⚑ flag

Export

1. developerExport the full source code and run or host the app outside the platform

   weight 3 · round to Lovable
   Lovable✓fullcommunity8/10

   Lovable explicitly supports downloading the full codebase or syncing to GitHub/GitLab, working locally in an IDE, and deploying outside Lovable via Git sync/export (lovable-docs-10, 14, 20, 33). Community comments (e.g. switching a Lovable-built site to Cursor/Astro) corroborate that exported code can be worked with outside the platform, though with quality caveats. Missing for 10: independent verification of a fully self-hostable backend (Supabase-based Cloud features may require re-setup outside Lovable), and no first-party doc detailing a clean 'run anywhere' deployment guide beyond GitHub sync.

   • [claimed-docs] “If you only need a copy of your code, you can download your code directly from Lovable: use the Download codebase section in Project setting…”
   • [claimed-docs] “you can export and sync your project to GitHub: back up your code, review changes in pull requests, work locally in your IDE, test features …”
   • [claimed-docs] “back up your code, review changes in pull requests, work locally in your IDE, test features on branches, and deploy outside Lovable”
   • [claimed-docs] “Git sync connects a Lovable project to a repository you own on GitHub or GitLab, and keeps the two in sync automatically”
   • [claimed-docs] “Work locally in your IDE. Clone the repository, edit and commit locally, and push. Your changes sync back into Lovable.”
   • [community] “Friend built a niche news site with Lovable using WordPress as headless CMS; Lovable built a monstrosity with Cloudflare workers, no proper …”

   proof ↗⚑ flag

   v0✓fullclaimed7/10

   v0 lets users connect a project to GitHub, push code directly to a repo, import existing GitHub code, and the API platform docs explicitly list 'Export capabilities for backup and migration,' meaning the generated code is not locked into the platform and can be run/hosted elsewhere. This is first-party documented but lacks independent hands-on verification of exporting and self-hosting outside Vercel's infrastructure. missing for 10: independent/community confirmation of exporting and successfully self-hosting a v0 app outside Vercel, and details on the exact export format/process.

   • [claimed-docs] “Connect to GitHub and push code directly to your repository.”
   • [claimed-docs] “Connect a v0 project to GitHub to keep its code in a repository, work on isolated branches, preview changes, run CI, and publish through pul…”
   • [claimed-docs] “To start from code already on GitHub, use Import from GitHub.”
   • [claimed-docs] “Export capabilities for backup and migration”
   • [claimed-docs] “GitHub integration for repository imports”

   proof ↗⚑ flag

2. developerWork on the app locally with my own editor and tooling and push changes back to the platform

   weight 2 · round to Lovable
   Lovable✓fullclaimed8/10

   Docs explicitly describe the Git sync workflow: clone repo, edit and commit locally in your own IDE, push changes, and they sync back into Lovable, plus code download and PR-based review/branch workflows for integrating with existing engineering tooling. Missing for 10: independent/hands-on confirmation that the local push-back sync works reliably without conflicts; community evidence focuses on generated code quality rather than the git-sync round-trip experience.

   • [claimed-docs] “Work locally in your IDE. Clone the repository, edit and commit locally, and push. Your changes sync back into Lovable.”
   • [claimed-docs] “Git sync connects a Lovable project to a repository you own on GitHub or GitLab, and keeps the two in sync automatically”
   • [claimed-docs] “you can export and sync your project to GitHub: back up your code, review changes in pull requests, work locally in your IDE, test features …”
   • [claimed-docs] “back up your code, review changes in pull requests, work locally in your IDE, test features on branches, and deploy outside Lovable”
   • [claimed-docs] “If you only need a copy of your code, you can download your code directly from Lovable: use the Download codebase section in Project setting…”

   proof ↗⚑ flag

   v0✓fullclaimed7/10

   v0's GitHub integration lets developers connect a project to a repo, work on isolated branches, push code directly, and open PRs — enabling a workflow where code can be edited locally and pushed back to sync with the platform. Missing for 10: explicit mention of a local CLI/dev-server workflow and independent confirmation that locally-pushed commits are correctly re-synced into the v0 chat/build pipeline.

   • [claimed-docs] “Connect a v0 project to GitHub to keep its code in a repository, work on isolated branches, preview changes, run CI, and publish through pul…”
   • [claimed-docs] “To start from code already on GitHub, use Import from GitHub.”
   • [claimed-docs] “To start from code already on GitHub, use Import from GitHub. Importing creates a chat at the selected base branch”
   • [claimed-docs] “Connect to GitHub and push code directly to your repository.”
   • [claimed-docs] “work on isolated branches, preview changes, run CI, and publish through pull requests”
   • [claimed-docs] “CI checks: See whether checks are running, passing, skipped, or failing.”
   • [claimed-docs] “open the branch menu and select Fix Conflicts, Fix CI, or Fix CI + Conflicts.”

   proof ↗⚑ flag

Git sync

1. developerSync my project to my own GitHub repository and keep changes flowing both ways

   weight 3 · round drawn
   Lovable✓fullclaimed8/10

   Lovable's Git sync explicitly connects a project to a repo you own on GitHub/GitLab and keeps them in sync automatically, supporting bidirectional flow (clone, edit, commit, push locally, changes sync back into Lovable) plus PR review workflows. missing for 10: independent/hands-on confirmation of sync reliability and edge-case handling (merge conflicts, large diffs) beyond first-party docs.

   • [claimed-docs] “Each project represents a single application and produces a codebase that can be synced to GitHub or GitLab with Git sync and integrated int…”
   • [claimed-docs] “Work locally in your IDE. Clone the repository, edit and commit locally, and push. Your changes sync back into Lovable.”
   • [claimed-docs] “you can export and sync your project to GitHub: back up your code, review changes in pull requests, work locally in your IDE, test features …”
   • [claimed-docs] “back up your code, review changes in pull requests, work locally in your IDE, test features on branches, and deploy outside Lovable”
   • [claimed-docs] “Git sync connects a Lovable project to a repository you own on GitHub or GitLab, and keeps the two in sync automatically”

   proof ↗⚑ flag

   v0✓fullclaimed8/10

   v0's docs describe robust two-way GitHub sync: connecting a project to a repo, working on isolated branches, previewing, running CI, publishing via PRs, importing existing GitHub code, and resolving conflicts/CI failures directly from v0 (v0-docs-2,3,26,27,30,39). This covers both directions of the sync story (v0→GitHub via branches/PRs, GitHub→v0 via import) with first-party specificity. Missing for 10: independent/hands-on community verification that the bidirectional sync works reliably in practice beyond vendor docs.

   • [claimed-docs] “Connect a v0 project to GitHub to keep its code in a repository, work on isolated branches, preview changes, run CI, and publish through pul…”
   • [claimed-docs] “To start from code already on GitHub, use Import from GitHub.”
   • [claimed-docs] “open the branch menu and select Fix Conflicts, Fix CI, or Fix CI + Conflicts.”
   • [claimed-docs] “To start from code already on GitHub, use Import from GitHub. Importing creates a chat at the selected base branch”
   • [claimed-docs] “CI checks: See whether checks are running, passing, skipped, or failing.”
   • [claimed-docs] “work on isolated branches, preview changes, run CI, and publish through pull requests”
   • [claimed-docs] “The Duplicate Branch dialog creates a new chat and branch containing the current branch's commits.”

   proof ↗⚑ flag

Collaboration

1. founderMy team can work on the same project together in a shared workspace

   weight 2 · round to Lovable
   Lovable✓fullclaimed8/10

   Lovable explicitly supports shared workspaces where teams can invite designers, developers, and others to collaborate in real time, with everyone seeing changes live, plus multi-person editing via separate drafts and workspace-level skills/enterprise access controls for teams. Missing for 10: independent hands-on validation of multi-user concurrency at scale and conflict resolution details beyond the 'draft' mechanism.

   • [claimed-docs] “Lovable lets you build websites together. Invite your designer, developer, agency, or anyone else. Everyone sees changes as they happen.”
   • [claimed-docs] “When several people build in the same project, each of you can work in your own draft: a separate copy of the project with its own chat and …”
   • [claimed-docs] “Invite your designer, developer, agency, or anyone else. Everyone sees changes as they happen.”
   • [claimed-docs] “Define a skill once at the workspace level, and Lovable can use it across every project in that workspace.”
   • [claimed-docs] “Anyone with an email address can sign up for free... Lovable automatically creates your first personal workspace on the free plan”
   • [claimed-docs] “centralized identity, granular access controls, workspace-wide security oversight, scheduled Deep scans, audit logs, regional code hosting”

   proof ↗⚑ flag

   v0~partialclaimed5/10

   v0 supports Projects with shared deployments, environment variables, and multiple chats connected to one project, plus a Shared Credit Pool for team plans, suggesting basic team collaboration on a shared project. However there's no evidence of real-time co-editing, granular roles/permissions, comments, or explicit multi-user workspace management beyond credit pooling. missing for 10: evidence of real-time multi-user collaboration, role-based permissions, in-app commenting/review, and explicit documentation of team workspace setup beyond credit sharing.

   • [claimed-docs] “One Project shares deployment, hosting, domains, and environment variables for the chats connected to it.”
   • [claimed-docs] “You can connect multiple chats to the same Project. This is useful when working different parts of one Project”
   • [claimed-docs] “When multiple chats share a Project, deploying from any of them updates the same production URL.”
   • [claimed-docs] “Shared Credit Pool credits are shared among all team members”

   proof ↗⚑ flag

Domains

1. founderConnect a custom domain to my published app

   weight 2 · round to Lovable
   Lovable✓fullclaimed8/10

   Lovable's docs explicitly cover custom domain connection, including buying, connecting, verifying, troubleshooting, and managing custom domains for a published app, replacing the default lovable.app URL. Missing for 10: independent/hands-on confirmation of the domain connection flow working smoothly (community evidence is silent on this specific feature).

   • [claimed-docs] “A custom domain lets you use your own domain or subdomain for your Lovable project instead of the default xxx.lovable.app URL.”
   • [claimed-docs] “A custom domain lets you use your own domain or subdomain for your Lovable project instead of the default xxx.lovable.app URL”
   • [claimed-docs] “A **custom domain** lets you use your own domain or subdomain for your Lovable project instead of the default `xxx.lovable.app` URL.”
   • [claimed-docs] “Learn how to buy, connect, verify, troubleshoot, and manage custom domains in Lovable.”
   • [claimed-docs] “Publishing turns your Lovable project into a live web app by deploying a snapshot to a URL you can share.”

   proof ↗⚑ flag

   v0~partialclaimed3/10

   Docs mention that Projects share 'deployment, hosting, domains, and environment variables' implying custom domain support exists at the project level, but there is no explicit guidance, UI flow, or confirmation of connecting a custom domain to a published app. missing for 10: dedicated custom-domain setup docs, DNS/verification steps, hands-on confirmation that a founder can attach their own domain.

   • [claimed-docs] “One Project shares deployment, hosting, domains, and environment variables for the chats connected to it.”
   • [claimed-docs] “Deploy with one click to secure, scalable infrastructure powered by Vercel.”
   • [claimed-docs] “Go live instantly with one-click deployment to production in seconds.”

   proof ↗⚑ flag

Publish

1. developerDeploy the generated app to an external host or my own infrastructure

   weight 1 · round to Lovable
   Lovable~partialclaimed6/10

   Docs confirm you can sync/export the generated codebase to GitHub/GitLab and explicitly state this lets you 'deploy outside Lovable' or download the code directly, satisfying the core ask, but Lovable's native workflow is oriented toward its own hosted 'Publish' and custom-domain features rather than first-class one-click integrations with external hosts (Vercel, AWS, etc.). Missing for 10: documented native deploy integrations/CI templates for specific external hosts, and independent hands-on confirmation that exported code deploys cleanly elsewhere.

   • [claimed-docs] “you can export and sync your project to GitHub: back up your code, review changes in pull requests, work locally in your IDE, test features …”
   • [claimed-docs] “back up your code, review changes in pull requests, work locally in your IDE, test features on branches, and deploy outside Lovable”
   • [claimed-docs] “If you only need a copy of your code, you can download your code directly from Lovable: use the Download codebase section in Project setting…”
   • [claimed-docs] “Git sync connects a Lovable project to a repository you own on GitHub or GitLab, and keeps the two in sync automatically”
   • [claimed-docs] “Code: Your app's source code, which you can browse, edit, and download.”

   proof ↗⚑ flag

   v0~partialclaimed5/10

   v0 emphasizes one-click deploy to Vercel's own infrastructure and GitHub push/export code, which allows deploying elsewhere via exported code, but there is no first-party support or documentation for direct deployment to non-Vercel hosts (e.g., AWS, Netlify, self-hosted servers) beyond pushing code to a repo. missing for 10: explicit support/instructions for deploying to external hosts or self-managed infrastructure beyond GitHub push, independent confirmation that exported/GitHub code deploys successfully outside Vercel.

   • [claimed-docs] “Deploy with one click to secure, scalable infrastructure powered by Vercel.”
   • [claimed-docs] “Connect to GitHub and push code directly to your repository.”
   • [claimed-docs] “Connect a v0 project to GitHub to keep its code in a repository, work on isolated branches, preview changes, run CI, and publish through pul…”
   • [claimed-docs] “Export capabilities for backup and migration”
   • [claimed-docs] “Go live instantly with one-click deployment to production in seconds.”

   proof ↗⚑ flag

2. founderPublish my app to a live URL in one step

   weight 3 · round to Lovable
   Lovable✓fullclaimed9/10

   Lovable's docs describe one-step publishing ("Publishing takes two clicks") that deploys a snapshot to a shareable live URL, plus chat-driven publish commands like 'publish my app' or 'ship it', directly matching the founder story. Custom domain support further extends this to branded URLs. Missing for 10: independent hands-on confirmation of the publish flow's simplicity (only vendor docs, no third-party corroboration of the exact one-click experience).

   • [claimed-docs] “Publishing turns your Lovable project into a live web app by deploying a snapshot to a URL you can share.”
   • [claimed-docs] “Publishing takes two clicks, and the defaults work for most projects”
   • [claimed-docs] “Ask Lovable to publish, deploy, ship, or go live, and it handles the deploy for you while respecting all publish-related workspace settings …”
   • [claimed-docs] “you can also ask Lovable to run project actions from chat, for example publish my app, deploy this project, ship it, or find me a domain for…”
   • [claimed-docs] “Build your first app and put it live on the web with about ten minutes of hands-on time. There is nothing to install and nothing to configur…”

   proof ↗⚑ flag

   v0✓fullcommunity8/10

   v0 docs explicitly describe one-click deploy to production via Vercel infrastructure, with project-level shared deployment URLs and instant go-live claims, corroborated by a community account of a full dev-to-deploy cycle to real users. Missing for 10: independent third-party verification of the exact one-step publish flow and no hands-on confirmation of custom domain setup ease.

   • [claimed-docs] “Deploy with one click to secure, scalable infrastructure powered by Vercel.”
   • [claimed-docs] “Go live instantly with one-click deployment to production in seconds.”
   • [claimed-docs] “When multiple chats share a Project, deploying from any of them updates the same production URL.”
   • [claimed-docs] “One Project shares deployment, hosting, domains, and environment variables for the chats connected to it.”
   • [community] “Built a feature-rich internal app (time tracker w/ auth, roles, export) and had a working MVP in users' hands by Monday. 'The speed was incr…”

   proof ↗⚑ flag

Agent integration

1. ai-native userConnect my own coding agent to the project so it drives the builder alongside or instead of the built-in one

   weight 2 · round to Lovable
   Lovable✓fullclaimed7/10

   Lovable ships an official MCP server (and desktop-app local MCP support) that lets an external AI agent create projects, send messages, inspect code, and deploy apps 'without leaving the client you're already working in,' which is exactly the story of connecting one's own coding agent to drive the project instead of/alongside the built-in one. Git sync also lets developers edit locally in their own IDE/agent and sync back into Lovable. Missing for 10: independent/hands-on evidence validating the MCP-driven workflow works well in practice, and more detail on how fully an external agent can 'replace' Build mode versus just issuing commands to it.

   • [claimed-docs] “your AI agent can create projects, send messages to Lovable, inspect code, deploy apps, and more, all without leaving the client you're alre…”
   • [claimed-docs] “You get everything in the web app plus local MCP server support, multi-project tabs, and keyboard shortcuts.”
   • [claimed-docs] “Git sync connects a Lovable project to a repository you own on GitHub or GitLab, and keeps the two in sync automatically”
   • [claimed-docs] “Work locally in your IDE. Clone the repository, edit and commit locally, and push. Your changes sync back into Lovable.”

   proof ↗⚑ flag

   v0~partialclaimed3/10

   The v0 API/SDK exposes programmatic access to v0's generation capabilities (e.g. v0.chats.create()) and GitHub integration for code sync, which could let an external tool or script drive v0 programmatically, but there is no evidence of a documented way to plug a third-party coding agent (e.g. Claude Code, Cursor) into a v0 project to replace or run alongside the built-in agent inside the builder UI. Missing for 10: explicit 'bring your own agent' support, agent-swap or multi-agent orchestration inside a v0 project, and any first-party or community confirmation of this working end-to-end.

   • [claimed-docs] “The v0 API gives you programmatic access to all of v0's capabilities, letting you integrate v0's AI-powered code generation, chat interface,…”
   • [claimed-docs] “Custom chat interfaces - Build your own UI for v0's AI-powered code generation”
   • [github] “const response = await v0.chats.create({ message: 'Build me a personal website', })”
   • [github] “Set V0_API_KEY, or deploy server-side code on Vercel with OIDC enabled, then use the default client.”
   • [claimed-docs] “Connect a v0 project to GitHub to keep its code in a repository, work on isolated branches, preview changes, run CI, and publish through pul…”

   proof ↗⚑ flag

Code editing

1. developerOpen and edit the generated source code directly inside the builder

   weight 2 · round to Lovable
   Lovable!disputedcontradicted5/10

   First-party docs explicitly state the Code tab lets you 'browse, edit, and download' source, and Build mode diffs are shown in-editor, supporting direct in-app code editing. However, an independent hands-on account reports that a Lovable project came with copy/paste disabled, directly undercutting the claim that generated code can be freely edited inside the builder. missing for 10: independent corroboration that in-editor code editing works unrestricted, clarification on why copy/paste was disabled in the reported case.

   • [claimed-docs] “Code: Your app's source code, which you can browse, edit, and download.”
   • [claimed-docs] “Lovable applies changes directly to your project when using Build mode. All modifications are visible through file diffs and summaries.”
   • [community] “Signed up for Lovable, picked a template, got a disclaimer to 'take responsibility over project security, compliance, data, operations' with…”

   proof ↗⚑ flag

   v0—none0/10

   The evidence pack describes visual controls, live preview, GitHub push/pull, and export capabilities, but never explicitly confirms an in-builder code editor where developers can directly view and edit the generated source files. Missing for 10: explicit documentation or screenshot of a code/editor pane inside the v0 builder, hands-on confirmation of direct code editing (not just prompting or visual controls).

   • [claimed-docs] “Fine-tune every detail with visual controls and live preview.”
   • [claimed-docs] “Connect to GitHub and push code directly to your repository.”
   • [claimed-docs] “Export capabilities for backup and migration”

   proof ↗⚑ flag

Preview

1. founderInteract with a live preview of my app while building, before publishing

   weight 2 · round drawn
   Lovable✓fullclaimed8/10

   Docs describe the core editor experience: users describe changes in chat and watch the app take shape in a live preview panel before publishing, with Build mode applying changes visibly via diffs and a separate explicit publish step. This directly matches the founder story of interacting with a live preview pre-publish. Missing for 10: no independent/hands-on account specifically confirming the live-preview interaction quality or responsiveness, and no detail on preview limitations (e.g., for complex backend/data scenarios).

   • [claimed-docs] “you describe what you want in the chat panel on the left, and you watch your app take shape in the preview on the right”
   • [claimed-docs] “Lovable applies changes directly to your project when using Build mode. All modifications are visible through file diffs and summaries.”
   • [claimed-docs] “Publishing turns your Lovable project into a live web app by deploying a snapshot to a URL you can share.”
   • [claimed-docs] “Ask Lovable to publish, deploy, ship, or go live, and it handles the deploy for you while respecting all publish-related workspace settings …”
   • [claimed-docs] “Lovable working on a request doesn't block you. Send a follow-up, a correction, or a new idea at any time to steer the work”

   proof ↗⚑ flag

   v0✓fullcommunity8/10

   v0's docs explicitly describe live preview with visual controls while iterating ('Fine-tune every detail with visual controls and live preview') and preview deployments built from working branches before publishing, matching the founder's need to see a live app preview pre-publish. Community evidence corroborates rapid build-to-preview workflows, though it's not preview-specific. Missing for 10: independent hands-on account specifically describing the live-preview interaction (vs generation speed) and detail on preview fidelity/limitations.

   • [claimed-docs] “Fine-tune every detail with visual controls and live preview.”
   • [claimed-docs] “Preview deployments are built from working branches.”
   • [community] “Built a feature-rich internal app (time tracker w/ auth, roles, export) and had a working MVP in users' hands by Monday. 'The speed was incr…”

   proof ↗⚑ flag

Prompt iteration

1. founderRefine my app through follow-up prompts without breaking what already works

   weight 3 · round drawn
   Lovable~partialcommunity5/10

   Docs confirm iterative refinement is core to Lovable's Build mode—users can send follow-ups, corrections, or new ideas at any time, with changes shown via diffs/summaries (lovable-docs-30, lovable-docs-43, lovable-docs-55)—but there's no explicit documentation of regression-safety or guarantees that new prompts won't break existing features. Community reports are mixed: some founders/PMs praise it for prototyping (lovable-comm-5, lovable-comm-13), while others note code quality degrades and complexity becomes unwieldy as apps grow (lovable-comm-9, lovable-comm-10), and one report cites frequent abandonment past 60-70% functionality (lovable-comm-7), suggesting iterative stability is not fully reliable at scale. missing for 10: explicit non-regression testing/safeguards, first-party evidence addressing 'without breaking existing functionality', and stronger independent confirmation of stable iterative editing on complex apps.

   • [claimed-docs] “Lovable working on a request doesn't block you. Send a follow-up, a correction, or a new idea at any time to steer the work”
   • [claimed-docs] “Lovable applies changes directly to your project when using Build mode. All modifications are visible through file diffs and summaries.”
   • [claimed-docs] “you describe what you want in the chat panel on the left, and you watch your app take shape in the preview on the right”
   • [community] “Startup CTO uses Lovable heavily for internal dashboards/CRUD tools; saved the equivalent of two full-time developers, but generated code is…”
   • [community] “"I recently used lovable to create the scaffolding for an app. It did a great job, far better than I expected. However, it also squishes eve…”
   • [community] “"I don't get how this company makes money. Everyone who uses these tools is just building prototypes. They get to 60-70% functionality, but …”
   • [community] “"I'm using Lovable heavily for PM prototyping and it's great. I think, if anything, current subscription may be too cheap!"”

   proof ↗⚑ flag

   v0~partialcommunity5/10

   v0 supports iterative refinement (chat-based prompts, automatic error fixing, isolated branches, project structure preserving deployment/config) and community reports confirm fast, incremental build-to-deploy cycles, but no evidence explicitly addresses preserving existing functionality across follow-up prompts or preventing regressions. missing for 10: explicit regression-safety guarantees, hands-on evidence that follow-up prompts don't break prior working features, independent testing of iterative stability.

   • [claimed-docs] “Automatically fix errors in your code with intelligent diagnostics.”
   • [claimed-docs] “v0 reads the relevant logs, diagnoses the failure, and applies a fix.”
   • [claimed-docs] “You can connect multiple chats to the same Project. This is useful when working different parts of one Project”
   • [claimed-docs] “One Project shares deployment, hosting, domains, and environment variables for the chats connected to it.”
   • [community] “Built a feature-rich internal app (time tracker w/ auth, roles, export) and had a working MVP in users' hands by Monday. 'The speed was incr…”

   proof ↗⚑ flag

Visual editing

1. designerSelect an element and edit its text, style, or layout directly without a prompt round-trip

   weight 2 · round to v0
   Lovable—none0/10

   All documented editing evidence describes prompt/chat-driven generation (chat panel + preview, Build/Agent mode acting on instructions) and code-level editing via IDE/download, not a visual direct-manipulation editor where a designer selects an element and tweaks text/style/layout inline without a prompt. No docs or community reports mention a click-to-select/inline style editor.

   • [claimed-docs] “you describe what you want in the chat panel on the left, and you watch your app take shape in the preview on the right”
   • [claimed-docs] “Lovable applies changes directly to your project when using Build mode. All modifications are visible through file diffs and summaries.”
   • [claimed-docs] “Code: Your app's source code, which you can browse, edit, and download.”
   • [claimed-docs] “Build mode (previously Agent mode) is Lovable's autonomous execution mode, designed to implement changes directly in your project. When you …”

   proof ↗⚑ flag

   v0~partialclaimed3/10

   v0.app claims 'Fine-tune every detail with visual controls and live preview' (v0-docs-7), suggesting some direct-manipulation UI, but nearly all other documentation describes chat/prompt-driven generation and iteration cycles rather than click-to-select element editing. Missing for 10: explicit documentation or demo of selecting an element on canvas and editing its text/style/layout inline, independent corroboration that this bypasses the prompt loop, and detail on what 'visual controls' actually cover.

   • [claimed-docs] “Fine-tune every detail with visual controls and live preview.”

   proof ↗⚑ flag

1. ai-native userDo everything through the API that I can do in the UI

   weight 2 · round drawn
   Lovable~partialprobed5/10

   Lovable exposes an official MCP server (and 'Build with URL' prompt links) letting an AI agent create projects, send messages, inspect code, and deploy apps 'without leaving the client' (lovable-docs-37, lovable-docs-53), which gives some programmatic parity with core chat/build/deploy actions. However, the probe found no public REST/OpenAPI spec (lovable-probe-2), and there's no evidence the API/MCP surface covers other UI capabilities like custom domains, security scans, collaboration/invites, billing, or database SQL editor access. Missing for 10: a documented general-purpose REST/GraphQL API, MCP/API coverage of domains, security scanning, collaboration, and billing equivalent to the UI.

   • [claimed-docs] “your AI agent can create projects, send messages to Lovable, inspect code, deploy apps, and more, all without leaving the client you're alre…”
   • [claimed-docs] “The Lovable API Build with URL feature lets you create links that open Lovable with a prompt already written, and optionally with reference …”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.lovable.dev/openapi.json, https://docs.lovable.dev/swagger.json, https://docs.lovable.d…”

   proof ↗⚑ flag

   v0~partialclaimed5/10

   v0 explicitly claims the API gives 'programmatic access to all of v0's capabilities' including chat, project management, and deployment (v0-docs-4), backed by SDK examples (v0-gh-1/2/3) and API docs on GitHub import and export (v0-docs-37, v0-docs-43). However, many UI-specific workflows (Figma/screenshot cloning, CI/conflict-fix buttons, command palette search, iOS app, visual style controls) are only documented as UI features with no API equivalent shown, and no independent test confirms true 1:1 parity. missing for 10: API-exposed equivalents for design import (Figma/screenshots), GitHub PR/CI-fix actions, and independent verification that API surface matches UI feature set.

   • [claimed-docs] “The v0 API gives you programmatic access to all of v0's capabilities, letting you integrate v0's AI-powered code generation, chat interface,…”
   • [claimed-docs] “GitHub integration for repository imports”
   • [claimed-docs] “Export capabilities for backup and migration”
   • [github] “const response = await v0.chats.create({ message: 'Build me a personal website', })”
   • [github] “Set V0_API_KEY, or deploy server-side code on Vercel with OIDC enabled, then use the default client.”
   • [claimed-docs] “Custom chat interfaces - Build your own UI for v0's AI-powered code generation”
   • [claimed-docs] “Clone pages with screenshots or Figma files”
   • [claimed-docs] “open the branch menu and select Fix Conflicts, Fix CI, or Fix CI + Conflicts.”

   proof ↗⚑ flag

2. ai-native userExport all of my data in open formats and leave

   weight 3 · round to Lovable
   Lovable~partialclaimed6/10

   Lovable lets users download or Git-sync the full generated codebase (open, standard code) and export to GitHub/GitLab for use outside the platform, which covers the 'code' portion of data export. However, the app's data (database records, user data) lives in Supabase-backed Cloud, and no docs describe a bulk data-export mechanism or open-format export of stored application data itself—only SQL editor access within the platform. missing for 10: documented database/data export (e.g., dump/backup) in open formats, and any evidence of a clean full account data export beyond code.

   • [claimed-docs] “Work locally in your IDE. Clone the repository, edit and commit locally, and push. Your changes sync back into Lovable.”
   • [claimed-docs] “If you only need a copy of your code, you can download your code directly from Lovable: use the Download codebase section in Project setting…”
   • [claimed-docs] “you can export and sync your project to GitHub: back up your code, review changes in pull requests, work locally in your IDE, test features …”
   • [claimed-docs] “back up your code, review changes in pull requests, work locally in your IDE, test features on branches, and deploy outside Lovable”
   • [claimed-docs] “Git sync connects a Lovable project to a repository you own on GitHub or GitLab, and keeps the two in sync automatically”
   • [claimed-docs] “For direct database access, use the SQL editor at **Cloud tab → SQL editor**”
   • [claimed-docs] “The built-in backend utilizes Supabase's open-source foundation, which means you get a production-ready environment from day one, without ne…”

   proof ↗⚑ flag

   v0~partialclaimed5/10

   v0 lets users push/export generated code to GitHub in a standard, open format (docs-2, docs-31, docs-39), and the API docs mention generic 'Export capabilities for backup and migration' (docs-43), supporting a degree of data portability. However there's no concrete evidence of exporting full account data (chat history, project settings, credentials) in open formats, and no independent confirmation the export path is complete or lock-in-free. Missing for 10: evidence of exporting non-code data (chats, project metadata, integrations config), a documented full-account export/download feature, and independent verification that migrated projects run outside v0/Vercel without further dependency.

   • [claimed-docs] “Connect a v0 project to GitHub to keep its code in a repository, work on isolated branches, preview changes, run CI, and publish through pul…”
   • [claimed-docs] “Connect to GitHub and push code directly to your repository.”
   • [claimed-docs] “work on isolated branches, preview changes, run CI, and publish through pull requests”
   • [claimed-docs] “Export capabilities for backup and migration”

   proof ↗⚑ flag

Pricing

1. founderUnderstand what credits or tokens each action consumes and what my plan includes

   weight 2 · round to Lovable
   Lovable~partialclaimed5/10

   Lovable docs mention a dedicated 'Plans & credit usage' settings page to track credit balance, usage, and top-ups (lovable-docs-59), which addresses the general need to monitor consumption. However there is no evidence of granular documentation showing what each specific action or message costs in credits, nor a clear breakdown of what different plans include, and no independent/community confirmation of pricing transparency. missing for 10: per-action credit cost breakdown, plan comparison details, independent user confirmation of pricing clarity.

   • [claimed-docs] “Use Settings → Plans & credit usage to understand your credit balance, track credit usage, add credits, and manage top-ups.”

   proof ↗⚑ flag

   v0!disputedcontradicted5/10

   Docs describe a credits/plan system (Premium $20/month, shared credit pools, ability to buy more credits) and even flag one action as token-free (v0-docs-10, v0-docs-23, v0-docs-42, v0-docs-25), but no documentation breaks down per-action credit costs. A hands-on community report contradicts the idea that users can predict consumption, describing unexpectedly high usage-based costs (~$50 in a weekend, '>$20/day') versus flat subscription alternatives (v0-comm-3), showing the credit model is opaque in practice. missing for 10: a clear per-action credit/token cost table, first-party UI showing real-time credit usage, and corroborating community confirmation that costs are predictable.

   • [claimed-docs] “You can buy more credits any time (Premium, Plus, and Business plans).”
   • [claimed-docs] “Premium: $20/month. For higher limits and power users.”
   • [claimed-docs] “Shared Credit Pool credits are shared among all team members”
   • [claimed-docs] “Start with existing files (fast, no tokens)”
   • [community] “Cost complaint: 'V0 is pay by usage... we talking > +$20/day vs $XX/month' for a subscription-based alternative like Copilot; spent about $5…”

   proof ↗⚑ flag

1. ai-native userChoose where my data is stored (region/residency)

   weight 2 · round to Lovable
   Lovable~partialclaimed4/10

   Lovable's enterprise docs mention 'regional code hosting' as one of several enterprise features, indicating some data residency control exists for enterprise customers, but there's no detail on which regions, how it's configured, or whether it applies to database/user data (vs just code) or non-enterprise plans. missing for 10: region selection details, database/data storage residency (not just code hosting), self-serve availability for non-enterprise users, independent confirmation.

   • [claimed-docs] “centralized identity, granular access controls, workspace-wide security oversight, scheduled Deep scans, audit logs, regional code hosting”

   proof ↗⚑ flag

   v0—none0/10

   No evidence in the pack mentions data residency, regional storage options, or any data-location controls for v0; the docs focus on code generation, deployment, GitHub integration, and pricing, none of which address where data is stored.

   ⚑ flag

2. ai-native userPrevent my data from being used to train AI models

   weight 3 · round drawn
   Lovable—none0/10

   No evidence pack item mentions data usage for AI training, opt-out settings, or any privacy policy language addressing this concern. Missing for 10: any documentation on training data opt-out, privacy policy statements, or enterprise data-handling guarantees regarding model training.

   ⚑ flag

   v0—none0/10

   No evidence in the pack addresses data-training opt-out, privacy controls, or any statement about whether user data/code is used to train AI models; nothing mentions a privacy policy toggle or enterprise no-training guarantee.

   ⚑ flag

3. ai-native userControl data retention and deletion

   weight 2 · round drawn
   Lovable—none0/10

   No evidence describes data retention policies, deletion workflows, or user controls for purging stored data/chat history; enterprise docs mention audit logs and regional hosting but not retention/deletion controls specifically.

   ⚑ flag

   v0—none0/10

   No evidence in the pack addresses data retention policies, deletion controls, or privacy settings for user data/chats/projects in v0; only export capabilities for backup/migration are mentioned, which is unrelated to retention/deletion control. Missing for 10: documented data retention policy, user-facing deletion/export-of-data controls, opt-out of training data usage, any privacy/compliance documentation.

   ⚑ flag

4. ai-native userOpt out of telemetry and usage tracking

   weight 2 · round drawn
   Lovable—none0/10

   No evidence in the pack mentions telemetry, analytics opt-out, or usage-tracking controls for Lovable users; docs focus on app-building features, security scanners, and integrations without any privacy/tracking settings mentioned.

   ⚑ flag

   v0—none0/10

   No evidence pack item mentions telemetry, analytics opt-out, or usage tracking controls for v0; nothing addresses privacy settings of this kind.

   ⚑ flag

Design import

1. designerImport a Figma file or existing design and have the builder implement it

   weight 2 · round to v0
   Lovable—none0/10

   No evidence in the pack shows Lovable can import a Figma file or existing design file and implement it; the closest mentions are attaching reference images/web pages to a prompt (lovable-docs-53) and a community comment contrasting Figma mockups with Lovable prototypes (lovable-comm-13), neither of which describes actual Figma file import.

   • [claimed-docs] “The Lovable API Build with URL feature lets you create links that open Lovable with a prompt already written, and optionally with reference …”
   • [community] “"As a product designer, I'm seriously looking at using Lovable for quick ideation and prototyping. Showing users a series of Figma screens c…”

   proof ↗⚑ flag

   v0~partialclaimed6/10

   Docs explicitly claim ability to 'Clone pages with screenshots or Figma files' and 'Create high-fidelity UIs from your wireframes or mockups,' directly supporting the story, but this is first-party doc text only with no workflow detail, screenshots, or independent hands-on confirmation of Figma import fidelity. Missing for 10: detailed Figma import workflow documentation, independent/community verification that Figma import works as claimed, and coverage of fidelity/limitations when translating Figma designs to code.

   • [claimed-docs] “Clone pages with screenshots or Figma files”
   • [claimed-docs] “Create high-fidelity UIs from your wireframes or mockups.”
   • [claimed-docs] “Turn mockups into real, high-fidelity user interfaces that reflect user flows and constraints.”

   proof ↗⚑ flag

Generation

1. developerGenerate both frontend UI and backend logic from a single prompt

   weight 3 · round drawn
   Lovable✓fullcommunity8/10

   Docs clearly describe generating a full app—frontend, backend, database, authentication—from a single natural-language prompt (lovable-docs-1, lovable-docs-27, lovable-docs-32, lovable-docs-5), with autonomous end-to-end execution (lovable-docs-4/29). Community reports corroborate real backend/CRUD apps being built (lovable-comm-9), though quality concerns exist (messy code, abandoned production use). Missing for 10: independent hands-on verification of true backend logic complexity beyond CRUD/dashboards, and confirmation that generated backend logic scales beyond prototypes.

   • [claimed-docs] “You describe what you want to build, and Lovable generates a working application that includes frontend, backend, database, authentication, …”
   • [claimed-docs] “Lovable hosts your app and includes a built-in backend (Cloud) with database, authentication, storage, edge functions, and AI, no infrastruc…”
   • [claimed-docs] “Describe the data your app needs in chat, and Lovable creates the tables and schema for you.”
   • [claimed-docs] “Ask Lovable to add login, and it generates the signup and login pages, wires them to your backend, and protects user data with row level sec…”
   • [claimed-docs] “Build mode (previously Agent mode) is Lovable's autonomous execution mode, designed to implement changes directly in your project. When you …”
   • [community] “Startup CTO uses Lovable heavily for internal dashboards/CRUD tools; saved the equivalent of two full-time developers, but generated code is…”

   proof ↗⚑ flag

   v0✓fullcommunity8/10

   v0 docs and community evidence show single-prompt generation of both frontend UI and connected backend logic (databases, auth, Supabase/Neon/Upstash integrations) plus full-stack scaffolding and deployment, corroborated by a hands-on HN report of building a full app with auth/roles/export from prompt to deployed MVP. missing for 10: no controlled benchmark of backend logic correctness/robustness, and no independent review specifically validating backend code quality (community feedback focuses mostly on UI generation and cost).

   • [claimed-docs] “Quickly scaffold full-stack apps or components following best practices and modern standards.”
   • [claimed-docs] “Connect to backend to build rich, data driven applications.”
   • [claimed-docs] “Available integrations include databases like Upstash for Redis and Neon for Serverless Postgres, backend services like Supabase, and AI mod…”
   • [claimed-docs] “v0 plans, creates tasks, and connects to databases as it builds.”
   • [claimed-docs] “Available integrations include databases like Upstash for Redis and Neon for Serverless Postgres, backend services like Supabase”
   • [community] “Built a feature-rich internal app (time tracker w/ auth, roles, export) and had a working MVP in users' hands by Monday. 'The speed was incr…”

   proof ↗⚑ flag

2. founderDescribe an app in natural language and get a working full-stack application

   weight 3 · round to v0
   Lovable~partialcommunity7/10

   Docs strongly support the core story: natural-language prompts generate a full-stack app (frontend, backend, database, auth, integrations) with built-in Cloud/Supabase backend and one-click publish (lovable-docs-1, lovable-docs-27, lovable-docs-31, lovable-docs-58). However, hands-on community reports show real caveats — generated apps can have performance/architecture problems (lovable-comm-1), code quality issues like unwieldy single-file structures and type-safety shortcuts (lovable-comm-9, lovable-comm-10), and reports that most projects stall at 60-70% functionality before production (lovable-comm-7, lovable-comm-8). Missing for 10: independent benchmark of end-to-end reliability across varied app types, and resolution of the production-readiness skepticism raised by users.

   • [claimed-docs] “You describe what you want to build, and Lovable generates a working application that includes frontend, backend, database, authentication, …”
   • [claimed-docs] “Lovable hosts your app and includes a built-in backend (Cloud) with database, authentication, storage, edge functions, and AI, no infrastruc…”
   • [claimed-docs] “Lovable hosts your app and includes a built-in backend (Cloud) with a database, storage, authentication, realtime, and functions.”
   • [claimed-docs] “Ask Lovable to publish, deploy, ship, or go live, and it handles the deploy for you while respecting all publish-related workspace settings …”
   • [community] “Friend built a niche news site with Lovable using WordPress as headless CMS; Lovable built a monstrosity with Cloudflare workers, no proper …”
   • [community] “Startup CTO uses Lovable heavily for internal dashboards/CRUD tools; saved the equivalent of two full-time developers, but generated code is…”
   • [community] “"I recently used lovable to create the scaffolding for an app. It did a great job, far better than I expected. However, it also squishes eve…”
   • [community] “"I don't get how this company makes money. Everyone who uses these tools is just building prototypes. They get to 60-70% functionality, but …”
   • [community] “"Lovable is a nice Website or App builder. Nothing for professionals, unless they want to build an prototype. Even building MVPs is nearly i…”

   proof ↗⚑ flag

   v0✓fullprobed8/10

   Docs and API show natural-language-to-app generation, full-stack scaffolding, backend/database integrations, and one-click deployment (v0-docs-15, v0-docs-24, v0-docs-28, v0-docs-32, v0-gh-1). A first-hand community report confirms a working MVP built and deployed quickly from a prompt (v0-comm-1). Missing for 10: broader independent benchmarking on complex, non-trivial apps and evidence addressing the noted design-sameness limitation (v0-comm-4).

   • [claimed-docs] “Quickly scaffold full-stack apps or components following best practices and modern standards.”
   • [claimed-docs] “Connect to backend to build rich, data driven applications.”
   • [claimed-docs] “Available integrations include databases like Upstash for Redis and Neon for Serverless Postgres, backend services like Supabase, and AI mod…”
   • [claimed-docs] “Go live instantly with one-click deployment to production in seconds.”
   • [github] “const response = await v0.chats.create({ message: 'Build me a personal website', })”
   • [community] “Built a feature-rich internal app (time tracker w/ auth, roles, export) and had a working MVP in users' hands by Monday. 'The speed was incr…”
   • [probe] “PROBE docs-md: HTTP 200 at https://v0.app/docs.md --- title: What is v0? description: v0 is an AI agent that helps anyone create real code a…”

   proof ↗⚑ flag

Programmatic generation

1. ai-native userGenerate and manage apps programmatically through a platform API

   weight 3 · round to v0
   Lovable~partialprobed6/10

   Lovable exposes a documented MCP server ('your AI agent can create projects, send messages to Lovable, inspect code, deploy apps, and more') and a 'Build with URL' feature for prompt-driven app creation, giving AI-native users a programmatic path to generate and manage apps. However, there is no traditional REST/GraphQL platform API — probe checks for openapi/swagger endpoints all returned 404 — so programmatic management is limited to MCP tool calls rather than a full API surface. Missing for 10: a documented public REST/GraphQL API with endpoints for project CRUD, deployment, and management outside the MCP/chat paradigm, and independent evidence of developers using it at scale.

   • [claimed-docs] “your AI agent can create projects, send messages to Lovable, inspect code, deploy apps, and more, all without leaving the client you're alre…”
   • [claimed-docs] “The Lovable API Build with URL feature lets you create links that open Lovable with a prompt already written, and optionally with reference …”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.lovable.dev/openapi.json, https://docs.lovable.dev/swagger.json, https://docs.lovable.d…”

   proof ↗⚑ flag

   v0✓fullclaimed8/10

   v0 documents a platform API that gives programmatic access to chat/code generation, project management, and deployment (v0-docs-4), and the official v0-sdk on GitHub shows concrete code for creating chats and streaming results with API-key auth (v0-gh-1, v0-gh-2, v0-gh-3), directly matching the 'generate and manage apps programmatically' story. Missing for 10: independent/hands-on corroboration of the API in production use and more detail on full app lifecycle management (list/delete/update) via the API beyond chat creation.

   • [claimed-docs] “The v0 API gives you programmatic access to all of v0's capabilities, letting you integrate v0's AI-powered code generation, chat interface,…”
   • [claimed-docs] “Custom chat interfaces - Build your own UI for v0's AI-powered code generation”
   • [claimed-docs] “Start with existing files (fast, no tokens)”
   • [claimed-docs] “GitHub integration for repository imports”
   • [claimed-docs] “Export capabilities for backup and migration”
   • [github] “const response = await v0.chats.create({ message: 'Build me a personal website', })”
   • [github] “const result = readV0Stream(serverResult.toResponse())”
   • [github] “Set V0_API_KEY, or deploy server-side code on Vercel with OIDC enabled, then use the default client.”

   proof ↗⚑ flag

Templates

1. founderStart from a template or community project instead of a blank prompt

   weight 2 · round to Lovable
   Lovable~partialclaimed5/10

   Docs mention 'Remixing' lets you create your own independent copy of an existing project to edit freely, which supports starting from a community project instead of a blank prompt, but there is no evidence of an explicit template gallery/marketplace or curated starter templates. missing for 10: dedicated template library/gallery, curated starter templates, independent confirmation of remix discoverability.

   • [claimed-docs] “Remixing creates your own independent copy that you can edit freely, on any plan.”

   proof ↗⚑ flag

   v0~partialcommunity4/10

   v0 supports starting from existing code via 'Import from GitHub' and 'Start with existing files (no tokens)', which lets founders begin from a pre-existing project rather than a blank prompt, and community testimony confirms it solves the 'blank canvas problem'. However there is no evidence of a curated template gallery or a community-project showcase/marketplace to browse and remix, which is the core of the story. Missing for 10: a dedicated template/starter gallery, community project discovery or remix feature, and evidence of founders actually starting from such templates.

   • [claimed-docs] “To start from code already on GitHub, use Import from GitHub.”
   • [claimed-docs] “To start from code already on GitHub, use Import from GitHub. Importing creates a chat at the selected base branch”
   • [claimed-docs] “Start with existing files (fast, no tokens)”
   • [community] “Built a feature-rich internal app (time tracker w/ auth, roles, export) and had a working MVP in users' hands by Monday. 'The speed was incr…”

   proof ↗⚑ flag