Lovable vs Bolt.new

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

   Bolt.new✓fullprobed8/10

   A direct probe confirms Bolt's support site serves a valid llms.txt file (HTTP 200) listing structured links to its docs, and the docs themselves are exposed in clean .md format suitable for agent consumption. This is concrete first-party evidence the capability works as claimed, not just a vendor claim. Missing for 10: no independent/community report of an agent actually consuming llms.txt in practice, and no evidence of additional agent-specific manifest formats beyond llms.txt.

   • [probe] “PROBE llms.txt: HTTP 200 at https://support.bolt.new/llms.txt # Bolt - [Intro to Bolt](https://support.bolt.new/get-started/intro-bolt.md):…”
   • [claimed-docs] “edit your code directly in code view”

   proof ↗⚑ flag

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

   weight 2 · round to Lovable
   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

   Bolt.new—none0/10

   Bolt.new is a browser-based, chat/UI-driven builder; no evidence of a CLI, API, or headless mode for CI/automation—OpenAPI probes 404 and docs describe only interactive web workflows (chat, code view, collaborate, publish). No mention of scriptable or non-interactive invocation exists in the evidence pack.

   • [probe] “PROBE openapi: all candidate paths 404 (https://support.bolt.new/openapi.json, https://support.bolt.new/swagger.json, https://support.bolt.n…”
   • [claimed-docs] “edit your code directly in code view”
   • [claimed-docs] “Bolt offers two agents, Standard and Max, powered by large language models.”

   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

   Bolt.new~partialclaimed5/10

   Bolt's docs mention a 'connect-mcp' page and a built-in GitHub MCP connector for searching code, issues, and discussions (bolt-docs-18, bolt-docs-40), showing MCP tool-use exists, but there's no evidence users can add arbitrary/custom MCP servers beyond the GitHub connector. missing for 10: documentation of adding custom/third-party MCP servers, evidence of general MCP server registration UI, and independent confirmation of multi-server support.

   • [claimed-docs] “Bolt also offers a GitHub MCP connector for tasks like searching code, pulling in issues, and reviewing discussions.”
   • [claimed-docs] “Connect to GitHub to let Bolt read or create issues and pull requests”

   proof ↗⚑ 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

   Bolt.new—none0/10

   Bolt.new is a browser-based AI app builder; evidence covers web-based agents, integrations, GitHub/MCP connectors, hosting, etc., but nowhere mentions an official CLI tool for interacting with Bolt.

   ⚑ flag

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

   weight 3 · round to Lovable
   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

   Bolt.new—none0/10

   No evidence of a documented public API for programmatically driving Bolt.new; the openapi probe returned 404 on all candidate paths and docs only describe UI-based features, integrations, and an MCP connector for GitHub (which lets Bolt consume other services, not expose its own API).

   • [probe] “PROBE openapi: all candidate paths 404 (https://support.bolt.new/openapi.json, https://support.bolt.new/swagger.json, https://support.bolt.n…”
   • [claimed-docs] “Bolt also offers a GitHub MCP connector for tasks like searching code, pulling in issues, and reviewing discussions.”
   • [claimed-docs] “Connect to GitHub to let Bolt read or create issues and pull requests”

   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

   Bolt.new—none0/10

   No evidence of any scoped or least-privilege API credential/token issuance for agents; docs mention collaborator roles and third-party integrations (GitHub, Supabase, Stripe) but nothing about generating restricted API keys or credentials for AI agents.

   ⚑ flag

7. ai-native userBuild against official SDKs

   weight 2 · round drawn
   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

   Bolt.new—none0/10

   Evidence shows no official SDK or public API for Bolt.new — the openapi probe returned 404s across all candidate endpoints and no docs mention an SDK; only import/integration features (GitHub, Figma, Supabase, Stripe) and an MCP connector for GitHub are documented, which are not the same as an SDK to build against Bolt itself.

   • [probe] “PROBE openapi: all candidate paths 404 (https://support.bolt.new/openapi.json, https://support.bolt.new/swagger.json, https://support.bolt.n…”
   • [claimed-docs] “Bolt also offers a GitHub MCP connector for tasks like searching code, pulling in issues, and reviewing discussions.”
   • [claimed-docs] “Connect to GitHub to let Bolt read or create issues and pull requests”

   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

   Bolt.new—none0/10

   No evidence of any webhook subscription mechanism; Bolt.new's docs cover MCP connectors, Git/Figma/Supabase/Stripe integrations, and hosting, but nothing about outbound event webhooks for AI-native automation.

   ⚑ flag

Agentic features

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

   weight 2 · round to Bolt.new
   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

   Bolt.new~partialclaimed5/10

   Bolt provides some AI-driven analysis of the project itself, e.g. automated security scanning ('Bolt can check your project for security problems and fix what it finds') and a 'Plan Mode' for AI-assisted planning/suggestions before code changes, which count as AI-generated insights on the user's data/project inside the product. However there is no evidence of broader data-analytics style insights (e.g. dashboards, trend analysis, or suggestions drawn from user-uploaded datasets) beyond code/security context. Missing for 10: evidence of general data-insight/analytics generation beyond code security, no independent corroboration of these insight features working well, no mention of insight capabilities for non-code data.

   • [claimed-docs] “Bolt can check your project for security problems and fix what it finds.”
   • [claimed-docs] “Bolt has a chat mode called Plan Mode where you can plan and ask questions without making changes to your code.”
   • [claimed-docs] “Bolt offers two agents, Standard and Max, powered by large language models.”

   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

   Bolt.new—none0/10

   No evidence of scheduled tasks, triggers, or any background/autonomous automation capability; Bolt.new is an interactive, prompt-driven builder that requires user presence in a session, not a system for setting up unattended background automations.

   ⚑ 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

   Bolt.new✓fullcommunity8/10

   Bolt.new's core function is AI-driven delegation: it offers built-in agents (Standard/Max) that autonomously control the environment (filesystem, terminal, package manager) and complete tasks from chat prompts, with automatic model routing and reusable 'skills'. Community reports confirm real task delegation success (e.g., building functional apps in minutes), though some hands-on reports note failure modes like doom loops or unauthorized changes, indicating reliability caveats. Missing for 10: independent benchmarking of agent reliability across diverse tasks, and clearer resolution of reported unauthorized-change incidents.

   • [claimed-docs] “Bolt offers two agents, Standard and Max, powered by large language models.”
   • [claimed-docs] “Bolt automatically routes to the right model for each task, balancing quality and cost.”
   • [github] “Bolt.new gives AI models complete control over the entire environment including the filesystem, node server, package manager, terminal, and …”
   • [claimed-docs] “Skills are reusable instructions that teach Bolt how to handle specific scenarios.”
   • [claimed-docs] “Bolt has a chat mode called Plan Mode where you can plan and ask questions without making changes to your code.”
   • [community] “i've seen people literally go from idea to prod in a day when it normally would take a week. Mind blowing.”
   • [community] “attempted to create a react app to plan meals... a functional app to edit ingredients, recipes and mealplans without data persistence that w…”
   • [community] “I've tried several proof of concepts with Bolt and every time just get into a doom loop where there is a cycle of breakage, each 'fix' resur…”

   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

   Bolt.new✓fullcommunity8/10

   Bolt.new is fundamentally an AI-native prompt-driven builder: users build apps, edit code, add databases, deploy, and even manage security fixes via natural-language chat with an agent, with community reports confirming '99% of edits made through prompts' and full apps built from idea to prod via chat. Plan Mode, Skills, Prompt Library, and visual edits further support natural-language operation as the primary interface. missing for 10: independent benchmarking of command coverage/reliability across all features, and some community reports of doom-loop breakage suggest imperfect execution under complex natural-language instructions.

   • [github] “Bolt.new gives AI models complete control over the entire environment including the filesystem, node server, package manager, terminal, and …”
   • [github] “Install and run npm tools and libraries (like Vite, Next.js, and more) - Run Node.js servers - Interact with third-party APIs - Deploy…”
   • [claimed-docs] “Bolt offers two agents, Standard and Max, powered by large language models.”
   • [claimed-docs] “Bolt has a chat mode called Plan Mode where you can plan and ask questions without making changes to your code.”
   • [claimed-docs] “Skills are reusable instructions that teach Bolt how to handle specific scenarios.”
   • [claimed-docs] “Save your prompts in the Prompt Library to reuse them later, and apply built-in prompts Bolt provides for common tasks.”
   • [community] “i've seen people literally go from idea to prod in a day when it normally would take a week. Mind blowing.”
   • [community] “was quite impressed after building my label maker application and stylex playground. Had some real world needs and both were built in bolt w…”
   • [community] “I've tried several proof of concepts with Bolt and every time just get into a doom loop where there is a cycle of breakage, each 'fix' resur…”

   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

   Bolt.new—none0/10

   The probe explicitly checked for OpenAPI/swagger endpoints and found all candidate paths returning 404, and no documentation mentions a machine-readable API spec for Bolt.new; only an llms.txt for docs discovery exists, which is not an API spec.

   • [probe] “PROBE openapi: all candidate paths 404 (https://support.bolt.new/openapi.json, https://support.bolt.new/swagger.json, https://support.bolt.n…”
   • [probe] “PROBE llms.txt: HTTP 200 at https://support.bolt.new/llms.txt # Bolt - [Intro to Bolt](https://support.bolt.new/get-started/intro-bolt.md):…”

   proof ↗⚑ flag

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

   weight 1 · round to Lovable
   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

   Bolt.new—none0/10

   The evidence pack shows Bolt integrates with Supabase and offers a built-in Database, plus hosting/visibility controls, but there is no mention anywhere of a staging/sandbox environment distinct from production, nor of safeguards preventing AI edits from touching live production data. Community reports (bolt-comm-7) even describe an incident where changes broke production payment functionality, reinforcing the absence of a sandbox separation feature.

   • [claimed-docs] “if you already have a Supabase account connected and need more advanced database features or tighter control over your data, choosing Supaba…”
   • [claimed-docs] “Supabase provides: A hosted SQL database... Authentication services... Edge functions”
   • [claimed-docs] “If you prefer to use Supabase when creating a new project, you can select it during setup.”
   • [claimed-docs] “Bolt makes it easy to add database functionality to your app without the hassle of extra infrastructure.”
   • [claimed-docs] “Use Supabase with Bolt to add a database, authentication, or edge functions to your app as an alternative to Bolt Database.”
   • [community] “Bolt.new's AI burned 10M tokens on unauthorized changes... removed critical systems like my FingerprintJS security layer without asking... T…”

   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

   Bolt.new—none0/10

   No evidence of a public versioned API, changelog, or deprecation policy for Bolt.new; the openapi probe returned 404s and no docs mention API versioning or deprecation.

   • [probe] “PROBE openapi: all candidate paths 404 (https://support.bolt.new/openapi.json, https://support.bolt.new/swagger.json, https://support.bolt.n…”

   proof ↗⚑ 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

   Bolt.new—none0/10

   Bolt.new is a single-project AI app builder with no evidence of batch/bulk operations across multiple items (e.g., bulk edits, batch API calls, multi-project automation). Its features are all single-project scoped (code view, collaboration, hosting, integrations) with no bulk-operation tooling mentioned. Missing for 10: any documentation of batch processing, multi-item automation, or bulk editing capability across projects or datasets.

   ⚑ 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

   Bolt.new—none0/10

   No evidence in the pack mentions scheduling, cron jobs, recurring workflows, or any automation trigger mechanism; Bolt.new's documented features are limited to app generation, integrations, and hosting.

   ⚑ flag

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

   weight 1 · round to Bolt.new
   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

   Bolt.new~partialcommunity6/10

   Bolt supports versioning via GitHub sync with full commit history (bolt-docs-2, bolt-docs-35) and branch work, plus a GitHub MCP connector for reviewing issues/PRs and discussions (bolt-docs-18, bolt-docs-40). Community evidence confirms users can 'revert and try with an updated prompt' as a practical rollback workflow (bolt-comm-10), though another user reports a 'doom loop' where fixes don't stick well (bolt-comm-9), showing rollback isn't always reliable. Missing for 10: a first-party documented in-app checkpoint/version-history or rollback UI (independent of external GitHub), and clearer review/approval workflow beyond raw GitHub PR access.

   • [claimed-docs] “Connect a GitHub repository to back up your Bolt project, sync commits automatically, and work across branches.”
   • [claimed-docs] “Connecting GitHub to Bolt lets you automatically back up your Bolt project with a full history of changes that lives outside Bolt.”
   • [claimed-docs] “Bolt also offers a GitHub MCP connector for tasks like searching code, pulling in issues, and reviewing discussions.”
   • [claimed-docs] “Connect to GitHub to let Bolt read or create issues and pull requests”
   • [community] “was quite impressed after building my label maker application and stylex playground. Had some real world needs and both were built in bolt w…”
   • [community] “I've tried several proof of concepts with Bolt and every time just get into a doom loop where there is a cycle of breakage, each 'fix' resur…”

   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

   Bolt.new—none0/10

   The evidence covers Bolt's own coding agents (Standard/Max) and model routing for generating code, plus integrations like Supabase/Stripe for database and payments, but there is no evidence of a managed service letting the *generated app* itself call LLMs or run agent features without the end-user supplying their own provider API keys.

   ⚑ 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

   Bolt.new~partialclaimed6/10

   Bolt's built-in Database docs explicitly describe scaffolding email sign-up ('users sign up using their email address') and Supabase integration adds broader 'Authentication services' when connected, so basic auth scaffolding is documented. However, no evidence specifically confirms social-provider (Google/GitHub/etc.) login scaffolding is generated by the builder—only generic 'authentication services' is mentioned. Missing for 10: explicit documentation or example of social/OAuth provider sign-up being scaffolded, and independent/hands-on confirmation that generated auth flows work reliably.

   • [claimed-docs] “This option allows your project's users to sign up using their email address.”
   • [claimed-docs] “Supabase provides: A hosted SQL database... Authentication services... Edge functions”
   • [claimed-docs] “Use Supabase with Bolt to add a database, authentication, or edge functions to your app as an alternative to Bolt Database.”
   • [claimed-docs] “Bolt makes it easy to add database functionality to your app without the hassle of extra infrastructure.”

   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

   Bolt.new~partialcommunity7/10

   Bolt ships a native 'Bolt Database' that can be added during project creation without extra infrastructure, plus an alternative Supabase integration offering hosted SQL, auth, and edge functions selectable at setup — both wired in without leaving the builder per docs [bolt-docs-33][bolt-docs-27][bolt-docs-22][bolt-docs-36][bolt-docs-34]. However, the Supabase path still requires connecting an external Supabase account [bolt-docs-8], and community reports describe friction after adding a database (token exhaustion, errors breaking the app) [bolt-comm-4], plus skepticism that outsourcing backend to Supabase limits robustness [bolt-comm-11]. Missing for 10: independent hands-on confirmation of a smooth, error-free end-to-end database provisioning flow, and clarity on whether Supabase setup ever requires leaving Bolt's UI.

   • [claimed-docs] “Bolt makes it easy to add database functionality to your app without the hassle of extra infrastructure.”
   • [claimed-docs] “If you prefer to use Supabase when creating a new project, you can select it during setup.”
   • [claimed-docs] “Supabase provides: A hosted SQL database... Authentication services... Edge functions”
   • [claimed-docs] “Use Supabase with Bolt to add a database, authentication, or edge functions to your app as an alternative to Bolt Database.”
   • [claimed-docs] “This option allows your project's users to sign up using their email address.”
   • [claimed-docs] “if you already have a Supabase account connected and need more advanced database features or tighter control over your data, choosing Supaba…”
   • [community] “attempted to create a react app to plan meals... a functional app to edit ingredients, recipes and mealplans without data persistence that w…”
   • [community] “Lovable and bolt took a massive shortcut: they outsourced the backend to a third party (supabase). This makes their ceiling to build 'useful…”

   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

   Bolt.new~partialclaimed5/10

   Bolt's docs explicitly claim a security review feature ('Bolt can check your project for security problems and fix what it finds'), directly matching the story, but this is a single thin doc line with no detail on scope, workflow integration before launch, or independent verification. Missing for 10: detailed documentation of what security checks are performed, evidence it runs automatically pre-launch, and independent/hands-on corroboration of its effectiveness.

   • [claimed-docs] “Bolt can check your project for security problems and fix what it finds.”

   proof ↗⚑ flag

Server logic

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

   weight 2 · round drawn
   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

   Bolt.new~partialcommunity6/10

   Bolt.new documents concrete backend/integration capabilities — Stripe for payments, Supabase for hosted SQL DB/auth/edge functions and email sign-up, and general Node.js server + third-party API support from the builder — which together map well onto 'server-side functions and integrations like payments/email.' However, a hands-on community report describes Bolt's agent breaking a live Stripe payment flow and removing security layers unexpectedly, showing real-world reliability gaps in production use of these integrations. missing for 10: independent success stories confirming stable payment/email integration in production, and clearer first-party detail on custom server-function authoring beyond Supabase edge functions.

   • [claimed-docs] “Bolt integrates directly with Stripe to handle user payments and subscriptions.”
   • [claimed-docs] “Supabase provides: A hosted SQL database... Authentication services... Edge functions”
   • [claimed-docs] “This option allows your project's users to sign up using their email address.”
   • [claimed-docs] “Use Supabase with Bolt to add a database, authentication, or edge functions to your app as an alternative to Bolt Database.”
   • [github] “Install and run npm tools and libraries (like Vite, Next.js, and more) - Run Node.js servers - Interact with third-party APIs - Deploy…”
   • [community] “Bolt.new's AI burned 10M tokens on unauthorized changes... removed critical systems like my FingerprintJS security layer without asking... T…”

   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

   Bolt.new✓fullclaimed7/10

   Docs confirm Bolt projects use standard code (Vite/Next.js etc.), that GitHub integration can create a repo from a Bolt project with full commit history 'that lives outside Bolt,' and that Code view exposes the raw project code for direct editing — together enabling export of the full source for use/hosting elsewhere. Missing for 10: explicit first-party instructions for running the exported repo locally/hosting it outside Bolt (e.g., 'npm install && npm run dev' after export) and independent hands-on confirmation that an exported project runs cleanly outside the platform.

   • [claimed-docs] “Connect a GitHub repository to back up your Bolt project, sync commits automatically, and work across branches.”
   • [claimed-docs] “Create a new repository from a Bolt project”
   • [claimed-docs] “Connecting GitHub to Bolt lets you automatically back up your Bolt project with a full history of changes that lives outside Bolt.”
   • [claimed-docs] “Code view allows you to view the raw code behind your project.”
   • [claimed-docs] “Choose your languages and frameworks, connect to source control, and edit your code directly in code view.”

   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

   Bolt.new~partialclaimed5/10

   Bolt supports GitHub sync (auto-backup, create repo, import repo) which lets code exist outside the platform, but there's no evidence of a true local-editor workflow — no CLI, no documented 'clone and push back' round-trip via local dev tools, and edits are primarily made in Bolt's own Code view or via GitHub, not confirmed to sync bidirectionally with arbitrary local pushes. missing for 10: documented local CLI/dev-server workflow, evidence of pushing local commits back into a running Bolt project, confirmation of bidirectional sync (not just backup/import).

   • [claimed-docs] “Connect a GitHub repository to back up your Bolt project, sync commits automatically, and work across branches.”
   • [claimed-docs] “Import a GitHub repository. Load an existing repository as a Bolt project.”
   • [claimed-docs] “Create a new repository from a Bolt project”
   • [claimed-docs] “Connecting GitHub to Bolt lets you automatically back up your Bolt project with a full history of changes that lives outside Bolt.”
   • [claimed-docs] “Choose your languages and frameworks, connect to source control, and edit your code directly in code view.”

   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

   Bolt.new✓fullclaimed8/10

   Docs clearly describe two-way GitHub sync: connecting a repo to back up and auto-sync commits with full history outside Bolt, importing an existing GitHub repo as a Bolt project, creating a new repo from a Bolt project, working across branches, and even a GitHub MCP connector for issues/PRs, plus direct code editing in code view. missing for 10: independent/hands-on confirmation that bidirectional sync (pushes from GitHub back into Bolt) works reliably in practice, and no community corroboration of this specific workflow.

   • [claimed-docs] “Connect a GitHub repository to back up your Bolt project, sync commits automatically, and work across branches.”
   • [claimed-docs] “Import a GitHub repository. Load an existing repository as a Bolt project.”
   • [claimed-docs] “Create a new repository from a Bolt project”
   • [claimed-docs] “Connecting GitHub to Bolt lets you automatically back up your Bolt project with a full history of changes that lives outside Bolt.”
   • [claimed-docs] “Choose your languages and frameworks, connect to source control, and edit your code directly in code view.”
   • [claimed-docs] “Bolt also offers a GitHub MCP connector for tasks like searching code, pulling in issues, and reviewing discussions.”
   • [claimed-docs] “Connect to GitHub to let Bolt read or create issues and pull requests”

   proof ↗⚑ flag

Collaboration

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

   weight 2 · round drawn
   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

   Bolt.new✓fullclaimed8/10

   Bolt documents real-time multiplayer collaboration, letting collaborators prompt and edit the same project simultaneously, inviting collaborators at any stage, and assigning roles to control access levels — directly matching the shared-workspace story. Missing for 10: independent/hands-on corroboration of multiplayer mode working smoothly at scale, and specifics on concurrency limits or conflict resolution.

   • [claimed-docs] “When your project visibility is set to public, collaborators can work together in multiplayer mode.”
   • [claimed-docs] “collaborators can work together in multiplayer mode. This lets you prompt and edit in the same project at the same time.”
   • [claimed-docs] “Work together in real time using multiplayer mode.”
   • [claimed-docs] “Bolt lets you invite collaborators to your project at any stage, whether you're still building, ready for review, or preparing to make your …”
   • [claimed-docs] “Assign collaborators a role that matches the level of access you want them to have.”

   proof ↗⚑ flag

Domains

1. founderConnect a custom domain to my published app

   weight 2 · round drawn
   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

   Bolt.new✓fullclaimed8/10

   Docs clearly document connecting a custom domain to a published Bolt project, either one already owned or purchased via Bolt (bolt-docs-12/16/23/28), alongside built-in bolt.host publishing (bolt-docs-32). Missing for 10: independent/hands-on confirmation of the custom domain flow working smoothly, and details on DNS setup specifics.

   • [claimed-docs] “you can attach a custom domain you own (like yoursite.com) or buy a domain through Bolt”
   • [claimed-docs] “you can attach a custom domain you own (like `yoursite.com`) or buy a domain through Bolt”
   • [claimed-docs] “you can attach a custom domain you own (like `yoursite.com`) or buy a domain through Bolt.”
   • [claimed-docs] “If you've already purchased a custom domain, you can connect it to your Bolt project.”
   • [claimed-docs] “Bolt offers built-in hosting, so you can publish your Bolt project for free at a web address ending in `bolt.host`.”

   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

   Bolt.new~partialclaimed5/10

   Bolt lets developers export code via GitHub (create/sync a repo) and view/edit raw code, which enables deploying that code to any external host or infrastructure of the developer's choosing; however, there is no first-party 'deploy to your own server/cloud' button—Bolt's built-in publish flow targets its own bolt.host hosting or custom domains attached to that hosting, not arbitrary external infrastructure. missing for 10: a documented one-click deploy target for external hosts (e.g., Vercel/Netlify/AWS), and independent confirmation that GitHub-exported code deploys successfully elsewhere.

   • [claimed-docs] “Connect a GitHub repository to back up your Bolt project, sync commits automatically, and work across branches.”
   • [claimed-docs] “Create a new repository from a Bolt project”
   • [claimed-docs] “Connecting GitHub to Bolt lets you automatically back up your Bolt project with a full history of changes that lives outside Bolt.”
   • [claimed-docs] “Code view allows you to view the raw code behind your project.”
   • [claimed-docs] “you can attach a custom domain you own (like yoursite.com) or buy a domain through Bolt”

   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

   Bolt.new✓fullclaimed8/10

   Bolt.new explicitly offers built-in one-click hosting to a bolt.host URL for free, plus custom domain attachment, and its own GitHub README states it can 'Deploy to production from chat,' directly matching the one-step publish story for founders. Visibility controls (public/private) and domain purchase/connect flows are also documented as part of this same publish step. missing for 10: independent/hands-on confirmation that the one-click publish flow works reliably in practice (no community reports specifically validating deployment simplicity or speed).

   • [claimed-docs] “Bolt offers built-in hosting, so you can publish your Bolt project for free at a web address ending in `bolt.host`.”
   • [claimed-docs] “you can attach a custom domain you own (like yoursite.com) or buy a domain through Bolt”
   • [claimed-docs] “you can attach a custom domain you own (like `yoursite.com`) or buy a domain through Bolt”
   • [claimed-docs] “you can attach a custom domain you own (like `yoursite.com`) or buy a domain through Bolt.”
   • [claimed-docs] “If you've already purchased a custom domain, you can connect it to your Bolt project.”
   • [claimed-docs] “When your site is private, only your team and invited users can see it.”
   • [claimed-docs] “you choose whether your site is visible to everyone on the web (public) or only to your team and other people you invite (private)”
   • [github] “Install and run npm tools and libraries (like Vite, Next.js, and more) - Run Node.js servers - Interact with third-party APIs - Deploy…”

   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

   Bolt.new—none0/10

   Evidence shows Bolt connecting outward to GitHub/MCP servers as a client (e.g., bolt-docs-18, bolt-docs-40) and offers its own built-in Standard/Max agents (bolt-docs-38), but there is no documentation or API allowing an external coding agent to connect to and drive the Bolt builder itself. Missing for 10: any API/CLI/agent-control interface for external agents to operate the builder, evidence of third-party agent integration replacing Bolt's own agent.

   • [claimed-docs] “Bolt offers two agents, Standard and Max, powered by large language models.”
   • [claimed-docs] “Bolt also offers a GitHub MCP connector for tasks like searching code, pulling in issues, and reviewing discussions.”
   • [claimed-docs] “Connect to GitHub to let Bolt read or create issues and pull requests”

   proof ↗⚑ flag

Code editing

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

   weight 2 · round to Bolt.new
   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

   Bolt.new✓fullclaimed9/10

   Bolt's docs clearly document a Code view where developers can view and directly edit the raw generated code, free of token cost, alongside source control integration for syncing changes. This is well documented across multiple first-party docs pages describing the exact capability requested. Missing for 10: independent hands-on confirmation of code-view editing specifically (community evidence focuses on prompting/iteration rather than manual code editing experience).

   • [claimed-docs] “edit your code directly in code view”
   • [claimed-docs] “you can still make direct edits to your project's existing code for free in Code view, which doesn't use tokens”
   • [claimed-docs] “Choose your languages and frameworks, connect to source control, and edit your code directly in code view.”
   • [claimed-docs] “connect to source control, and edit your code directly in code view”
   • [claimed-docs] “Code view allows you to view the raw code behind your project.”

   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

   Bolt.new✓fullclaimed8/10

   Bolt provides a live preview alongside chat/code editing, including 'Visual edits' that let founders change appearance directly in the preview before publishing, plus Code view and Plan Mode for iterating pre-publish. Missing for 10: independent hands-on confirmation specifically of the live preview UX (most community evidence is about final output quality/breakage rather than the preview interaction itself), and no detail on preview refresh/latency behavior.

   • [claimed-docs] “Visual edits let you change how your project looks directly in the preview.”
   • [claimed-docs] “Code view allows you to view the raw code behind your project.”
   • [claimed-docs] “Bolt has a chat mode called Plan Mode where you can plan and ask questions without making changes to your code.”
   • [claimed-docs] “Build your first website or app with Bolt: no code required.”
   • [claimed-docs] “you choose whether your site is visible to everyone on the web (public) or only to your team and other people you invite (private)”

   proof ↗⚑ flag

Prompt iteration

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

   weight 3 · round to Lovable
   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

   Bolt.new!disputedcontradicted4/10

   Bolt offers features that support iterative refinement (Plan Mode for planning without code changes, Code view/direct edits, GitHub backup for version history, Skills for reusable instructions), but concrete hands-on reports directly contradict the 'without breaking what already works' promise: one founder reports Bolt's AI made unauthorized changes that removed a security layer and killed payment functionality, and another describes a recurring 'doom loop where there is a cycle of breakage, each fix resurrecting a previous break,' with users advising to revert rather than try to fix in place. missing for 10: first-party evidence of safe-iteration mechanisms like automatic checkpoints/rollback specifically preventing regressions, and independent confirmation that follow-up prompts reliably preserve prior functionality.

   • [claimed-docs] “Bolt has a chat mode called Plan Mode where you can plan and ask questions without making changes to your code.”
   • [claimed-docs] “Code view allows you to view the raw code behind your project.”
   • [claimed-docs] “Connecting GitHub to Bolt lets you automatically back up your Bolt project with a full history of changes that lives outside Bolt.”
   • [claimed-docs] “Skills are reusable instructions that teach Bolt how to handle specific scenarios.”
   • [community] “Bolt.new's AI burned 10M tokens on unauthorized changes... removed critical systems like my FingerprintJS security layer without asking... T…”
   • [community] “I've tried several proof of concepts with Bolt and every time just get into a doom loop where there is a cycle of breakage, each 'fix' resur…”
   • [community] “was quite impressed after building my label maker application and stylex playground. Had some real world needs and both were built in bolt w…”

   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 Bolt.new
   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

   Bolt.new~partialclaimed6/10

   Bolt's Visual Edits feature lets users change how a project looks directly in the preview without prompting [bolt-docs-44], and Code view supports direct manual edits [bolt-docs-45, bolt-docs-3]. However, evidence doesn't confirm true element-select-and-edit for layout/structure (not just style) or independent hands-on validation of Visual Edits' scope. missing for 10: independent/community confirmation of Visual Edits reliability, detail on whether layout (not just style/text) is editable via the visual UI, and any limitations noted by users.

   • [claimed-docs] “Visual edits let you change how your project looks directly in the preview.”
   • [claimed-docs] “Code view allows you to view the raw code behind your project.”
   • [claimed-docs] “you can still make direct edits to your project's existing code for free in Code view, which doesn't use tokens”

   proof ↗⚑ flag

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

   weight 2 · round to Lovable
   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

   Bolt.new—none0/10

   There is no evidence Bolt.new exposes any public API at all — probes for OpenAPI/swagger endpoints all returned 404, and all documented capabilities (code view, GitHub sync, Figma import, Supabase, hosting, collaboration) are described only as UI/chat features. No documentation mentions a REST/GraphQL API, CLI, or SDK that would let an AI-native user replicate UI actions programmatically.

   • [probe] “PROBE openapi: all candidate paths 404 (https://support.bolt.new/openapi.json, https://support.bolt.new/swagger.json, https://support.bolt.n…”
   • [claimed-docs] “edit your code directly in code view”
   • [claimed-docs] “Choose your languages and frameworks, connect to source control, and edit your code directly in code view.”
   • [claimed-docs] “Bolt offers two agents, Standard and Max, powered by large language models.”

   proof ↗⚑ flag

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

   weight 3 · round drawn
   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

   Bolt.new~partialclaimed6/10

   Bolt lets users connect/export projects to GitHub with full commit history and edit raw code in Code view, letting a user leave with their code in an open, standard format (bolt-docs-2, bolt-docs-4, bolt-docs-30, bolt-docs-35, bolt-docs-45). However there's no documented mechanism to export other data such as chat/prompt history, project metadata, database contents beyond using Supabase, or account data in a single open bundle. Missing for 10: full account/data export beyond code (chat history, prompt library, non-Supabase DB export), independent confirmation that exported repos are fully self-contained with no bolt.new lock-in.

   • [claimed-docs] “Connect a GitHub repository to back up your Bolt project, sync commits automatically, and work across branches.”
   • [claimed-docs] “Import a GitHub repository. Load an existing repository as a Bolt project.”
   • [claimed-docs] “Create a new repository from a Bolt project”
   • [claimed-docs] “Connecting GitHub to Bolt lets you automatically back up your Bolt project with a full history of changes that lives outside Bolt.”
   • [claimed-docs] “Code view allows you to view the raw code behind your project.”
   • [claimed-docs] “Bolt makes it easy to add database functionality to your app without the hassle of extra infrastructure.”
   • [claimed-docs] “Use Supabase with Bolt to add a database, authentication, or edge functions to your app as an alternative to Bolt Database.”

   proof ↗⚑ flag

3. ai-native userSelf-host the core product

   weight 3 · round drawn
   Lovable—none0/10

   Lovable is presented throughout its docs as a fully hosted SaaS (Cloud backend, hosted publish/deploy, workspace plans) with no mention of a self-hostable core product, on-prem deployment, or open-source distribution; you can only export/download generated app code, not the Lovable platform itself.

   • [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] “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…”
   • [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

   Bolt.new—none0/10

   While a GitHub repository for bolt.new exists (bolt-gh-1–4), the evidence pack contains no documentation, instructions, or claims about deploying/self-hosting the core Bolt.new product on one's own infrastructure — all cited docs describe the hosted SaaS experience (hosting on bolt.host, custom domains, Supabase, etc.). No evidence confirms an official self-host path.

   ⚑ 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

   Bolt.new~partialcommunity3/10

   Docs mention that code-view edits are free (no tokens) and that additional tokens can be purchased, but there is no clear breakdown of how many tokens each specific AI action costs or what token allotments come with each plan tier. Community reports of running out of free tokens mid-project and of the AI 'burning 10M tokens' on unauthorized changes suggest actual consumption is unpredictable and not well understood by users. missing for 10: per-action token cost table, plan-tier token allotments, first-party pricing page detail, and independent confirmation that users can predict usage.

   • [claimed-docs] “you can still make direct edits to your project's existing code for free in Code view, which doesn't use tokens”
   • [claimed-docs] “you can purchase additional tokens by following the steps below”
   • [community] “attempted to create a react app to plan meals... a functional app to edit ingredients, recipes and mealplans without data persistence that w…”
   • [community] “Bolt.new's AI burned 10M tokens on unauthorized changes... removed critical systems like my FingerprintJS security layer without asking... T…”

   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

   Bolt.new—none0/10

   No evidence in the pack mentions data residency, regional storage options, or compliance controls for choosing where data is stored; Bolt's docs cover hosting, database, and integrations but never address data-location choice.

   ⚑ 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

   Bolt.new—none0/10

   No evidence in the pack addresses AI training data opt-out, data usage policies, or privacy controls related to model training on user data; all evidence covers unrelated features like integrations, hosting, and collaboration.

   ⚑ 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

   Bolt.new—none0/10

   No evidence pack items address data retention policies, data deletion controls, or privacy settings for user data/projects; documentation covers hosting, collaboration, integrations, and agent features but nothing about retention/deletion controls.

   ⚑ 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

   Bolt.new—none0/10

   No evidence pack item mentions telemetry, analytics opt-out, or usage-tracking controls for Bolt.new; documentation covers integrations, hosting, agents, and collaboration but is silent on privacy/telemetry settings.

   ⚑ flag

Design import

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

   weight 2 · round to Bolt.new
   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

   Bolt.new✓fullclaimed8/10

   Bolt has a dedicated Figma integration that loads Figma frames/designs and generates working UIs, including a design-system agent that recreates frames using real design system components, plus similar import support for Google Stitch designs. Missing for 10: independent/hands-on evidence of Figma import fidelity and no detail on handling complex multi-page files.

   • [claimed-docs] “you can quickly load Figma designs into Bolt, and generate sites and UIs based on the designs”
   • [claimed-docs] “adding a design system can help build your Figma frames into working webpages”
   • [claimed-docs] “Using Bolt's Figma integration, you can quickly load Figma designs into Bolt, and generate sites and UIs based on the designs.”
   • [claimed-docs] “Bolt's design system agent processes the frame and recreates it using your real design system components.”
   • [claimed-docs] “you can quickly load Figma designs into Bolt, and generate sites and UIs based on the designs.”
   • [claimed-docs] “Anyone can start from a blank prompt, upload files to build with, or import designs from Figma or Google Stitch.”
   • [claimed-docs] “Export your Google Stitch designs to Bolt and build them into a fully functional app.”

   proof ↗⚑ flag

Generation

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

   weight 3 · round to Lovable
   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

   Bolt.new~partialcommunity6/10

   Bolt.new documents generating full frontend UIs (Vite/Next.js) plus backend logic via Node servers, third-party API integration, and database/auth via Bolt Database or Supabase, and community reports confirm working full-stack apps (e.g., meal-planner with persistence) built from prompts alone [bolt-gh-1][bolt-gh-3][bolt-docs-33][bolt-docs-27][bolt-comm-4]. However, backend depth is largely delegated to a third-party service (Supabase) rather than fully custom logic, and hands-on reports cite backend breakage, doom-loop failures, and unauthorized removal of critical backend systems [bolt-comm-11][bolt-comm-9][bolt-comm-7]. Missing for 10: independent verification of complex custom backend logic beyond Supabase/Stripe integrations, and resolution of reported reliability issues with backend generation.

   • [github] “Install and run npm tools and libraries (like Vite, Next.js, and more) Run Node.js servers”
   • [github] “Install and run npm tools and libraries (like Vite, Next.js, and more) - Run Node.js servers - Interact with third-party APIs - Deploy…”
   • [claimed-docs] “Bolt makes it easy to add database functionality to your app without the hassle of extra infrastructure.”
   • [claimed-docs] “If you prefer to use Supabase when creating a new project, you can select it during setup.”
   • [claimed-docs] “if you already have a Supabase account connected and need more advanced database features or tighter control over your data, choosing Supaba…”
   • [community] “attempted to create a react app to plan meals... a functional app to edit ingredients, recipes and mealplans without data persistence that w…”
   • [community] “Lovable and bolt took a massive shortcut: they outsourced the backend to a third party (supabase). This makes their ceiling to build 'useful…”
   • [community] “I've tried several proof of concepts with Bolt and every time just get into a doom loop where there is a cycle of breakage, each 'fix' resur…”
   • [community] “Bolt.new's AI burned 10M tokens on unauthorized changes... removed critical systems like my FingerprintJS security layer without asking... T…”

   proof ↗⚑ flag

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

   weight 3 · round to Lovable
   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

   Bolt.new!disputedcontradicted6/10

   Bolt's docs and product clearly support prompt-to-app generation with built-in database, auth, hosting, and deployment (bolt-docs-31, bolt-docs-33, bolt-docs-32, bolt-gh-3), and multiple community testimonials confirm fast working builds (bolt-comm-3, bolt-comm-4, bolt-comm-10). However, concrete hands-on reports contradict reliable full-stack delivery: users describe 'doom loop' cycles of breakage where fixes resurrect prior bugs (bolt-comm-9), and one detailed account describes the AI making unauthorized changes that broke critical security and payment systems in a deployed app (bolt-comm-7). Missing for 10: consistent reproducibility across complex apps, resolution of the doom-loop/breakage pattern, and vendor response addressing these failures.

   • [claimed-docs] “Build your first website or app with Bolt: no code required.”
   • [claimed-docs] “Bolt makes it easy to add database functionality to your app without the hassle of extra infrastructure.”
   • [claimed-docs] “Bolt offers built-in hosting, so you can publish your Bolt project for free at a web address ending in `bolt.host`.”
   • [github] “Install and run npm tools and libraries (like Vite, Next.js, and more) - Run Node.js servers - Interact with third-party APIs - Deploy…”
   • [community] “i've seen people literally go from idea to prod in a day when it normally would take a week. Mind blowing.”
   • [community] “attempted to create a react app to plan meals... a functional app to edit ingredients, recipes and mealplans without data persistence that w…”
   • [community] “was quite impressed after building my label maker application and stylex playground. Had some real world needs and both were built in bolt w…”
   • [community] “I've tried several proof of concepts with Bolt and every time just get into a doom loop where there is a cycle of breakage, each 'fix' resur…”
   • [community] “Bolt.new's AI burned 10M tokens on unauthorized changes... removed critical systems like my FingerprintJS security layer without asking... T…”

   proof ↗⚑ flag

Programmatic generation

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

   weight 3 · round to Lovable
   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

   Bolt.new—none0/10

   No evidence of a public/programmatic API for creating or managing Bolt projects; the OpenAPI probe returned 404 on all candidate endpoints, and all documented capabilities (chat, code view, GitHub sync, MCP connector) are UI/agent-driven rather than API-driven.

   • [probe] “PROBE openapi: all candidate paths 404 (https://support.bolt.new/openapi.json, https://support.bolt.new/swagger.json, https://support.bolt.n…”
   • [claimed-docs] “Bolt also offers a GitHub MCP connector for tasks like searching code, pulling in issues, and reviewing discussions.”
   • [claimed-docs] “Connect to GitHub to let Bolt read or create issues and pull requests”

   proof ↗⚑ flag

Templates

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

   weight 2 · round to Bolt.new
   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

   Bolt.new~partialclaimed7/10

   Bolt lets founders start from something other than a blank prompt: import a GitHub repo, import a Lovable project, load Figma or Google Stitch designs, or upload files (bolt-docs-4,5,6,7,49). However there's no evidence of a curated template gallery or a browsable community-project marketplace like some competitors offer. missing for 10: a dedicated templates/starter gallery, evidence of browsing/forking community-submitted projects.

   • [claimed-docs] “Import a GitHub repository. Load an existing repository as a Bolt project.”
   • [claimed-docs] “Import from Lovable. Bring a Lovable project into Bolt.”
   • [claimed-docs] “you can quickly load Figma designs into Bolt, and generate sites and UIs based on the designs”
   • [claimed-docs] “Export your Google Stitch designs to Bolt and build them into a fully functional app.”
   • [claimed-docs] “Anyone can start from a blank prompt, upload files to build with, or import designs from Figma or Google Stitch.”
   • [claimed-docs] “Build your first website or app with Bolt: no code required.”

   proof ↗⚑ flag