Lovable vs Replit

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

   Replit✓fullprobed8/10

   A probe confirms Replit docs serve a working llms.txt at docs.replit.com/llms.txt (HTTP 200) listing structured doc sections, directly enabling an agent to be pointed at agent-oriented docs; this is corroborated by extensive first-party docs pages formatted for agent consumption. Missing for 10: independent third-party confirmation that agents actually consume/use this llms.txt effectively, and no evidence of an OpenAPI spec or other machine-readable API docs (all probed paths 404).

   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.replit.com/llms.txt # Replit - [Features (218 pages)](https://docs.replit.com/_llms/en/features.md…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.replit.com/openapi.json, https://docs.replit.com/swagger.json, https://docs.replit.com/…”
   • [claimed-docs] “Replit Agent can connect to hundreds of external tools and data sources through the Model Context Protocol (MCP)”

   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

   Replit—none0/10

   Evidence covers Replit's Agent modes, MCP connectors, and scheduled 'routines' but nothing about a CLI, API, or headless mode for running Replit in CI/automation pipelines outside its own UI. missing for 10: CLI/API for headless execution, CI/CD pipeline integration, documented automation outside Replit's own scheduler.

   • [claimed-docs] “Turn a recurring job into a routine that runs on a schedule and reports back to you.”
   • [claimed-docs] “Agent Modes let you choose the balance between included allowance, credits, and capability before you send a request.”
   • [claimed-docs] “Choose Free Mode, Power Mode, or Max Mode based on the work you want to do, the capability you need, and your available allowance or credits…”

   proof ↗⚑ flag

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

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

   Replit✓fullclaimed8/10

   Replit's docs explicitly describe connecting Agent to external tools via MCP, with a curated catalog (Stripe, Linear, Notion, Sentry) plus the ability to add custom servers by URL, giving Agent access to their tools. missing for 10: independent/hands-on community corroboration of MCP usage in practice, and detail on tool invocation reliability beyond first-party docs.

   • [claimed-docs] “Replit Agent can connect to hundreds of external tools and data sources through the Model Context Protocol (MCP)”
   • [claimed-docs] “Connect your tools, add reusable Skills, and extend Replit with MCP.”
   • [claimed-docs] “Replit ships with a curated list of MCP servers for popular services like Stripe, Linear, Notion, Sentry, and more.”
   • [claimed-docs] “If the server you want isn't in the pre-listed catalog, add it by URL.”
   • [claimed-docs] “Connect Replit Agent to external tools, data sources, and APIs through the Model Context Protocol (MCP) — sign in to a pre-listed server or …”

   proof ↗⚑ flag

4. ai-native userConnect an agent via an official MCP server

   weight 3 · round to Lovable
   Lovable✓fullclaimed8/10

   Lovable documents an official MCP server integration: an AI agent can create projects, send messages to Lovable, inspect code, deploy apps, and more via the Lovable MCP server, plus local MCP server support in the desktop app and the ability to turn published apps into MCP servers for ChatGPT/Claude. Missing for 10: independent/hands-on confirmation that the official MCP server works as documented, and more detail on setup/auth flow beyond the docs summary.

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

   proof ↗⚑ flag

   Replit✓fullclaimed7/10

   Replit documents an official Replit MCP Server that external compatible clients can connect to in order to create, inspect, or update Replit Apps (replit-docs-42), which is exactly the story of connecting an agent via an official MCP server (distinct from Replit Agent acting as an MCP client to third-party services, e.g. replit-docs-12/20/41). This is first-party documented capability with a dedicated docs page (connect-through-mcp.md). Missing for 10: independent/hands-on corroboration of connecting an external agent to Replit's MCP server, and more detail on auth/setup flow or limitations.

   • [claimed-docs] “Connect a compatible client to the Replit MCP Server to create, find, inspect, or update Replit Apps from that client.”
   • [claimed-docs] “Connect Replit Agent to external tools, data sources, and APIs through the Model Context Protocol (MCP) — sign in to a pre-listed server or …”
   • [claimed-docs] “Replit ships with a curated list of MCP servers for popular services like Stripe, Linear, Notion, Sentry, and more.”

   proof ↗⚑ flag

5. 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

   Replit—none0/10

   Evidence covers Replit's web/desktop/mobile apps, Agent, MCP integrations, and deployments, but nowhere mentions an official CLI tool for AI-native workflows. Absence of evidence for this applicable capability means 'none' rather than 'na'.

   ⚑ flag

6. 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

   Replit~partialprobed5/10

   Replit documents an MCP server that lets external clients create, find, inspect, or update Replit Apps (replit-docs-42), which functions as a documented programmatic interface for AI-native control, but there is no evidence of a traditional REST/OpenAPI-documented public API — probes for openapi.json/swagger.json all returned 404 (replit-probe-2). missing for 10: a formal REST/OpenAPI-documented API, independent confirmation of MCP server reliability/completeness, broader API surface beyond MCP-driven app management.

   • [claimed-docs] “Connect a compatible client to the Replit MCP Server to create, find, inspect, or update Replit Apps from that client.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.replit.com/openapi.json, https://docs.replit.com/swagger.json, https://docs.replit.com/…”
   • [claimed-docs] “Replit Agent can connect to hundreds of external tools and data sources through the Model Context Protocol (MCP)”
   • [claimed-docs] “Connect Replit Agent to external tools, data sources, and APIs through the Model Context Protocol (MCP) — sign in to a pre-listed server or …”

   proof ↗⚑ flag

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

   Replit—none0/10

   Evidence covers built-in auth for end-user apps and centralized connector management, but there is no documentation of issuing scoped or least-privilege API credentials specifically to control an agent's own access level. Missing for 10: any mention of API key/credential scoping, permission levels, or least-privilege token issuance for the agent itself.

   ⚑ flag

8. 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

   Replit—none0/10

   The evidence pack describes MCP-based integrations, connectors, and Agent Skills, but never mentions an official SDK (e.g., a Python/JS client library) for programmatically building against Replit, and a direct probe for an OpenAPI/API spec returned 404s on all candidate paths, suggesting no public SDK/API surface is documented.

   • [claimed-docs] “Replit Agent can connect to hundreds of external tools and data sources through the Model Context Protocol (MCP)”
   • [claimed-docs] “Connect your tools, add reusable Skills, and extend Replit with MCP.”
   • [claimed-docs] “Connect Replit Agent to external tools, data sources, and APIs through the Model Context Protocol (MCP) — sign in to a pre-listed server or …”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.replit.com/openapi.json, https://docs.replit.com/swagger.json, https://docs.replit.com/…”

   proof ↗⚑ flag

9. 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

   Replit—none0/10

   No evidence in the pack mentions webhooks, event subscriptions, or a mechanism for Replit apps/agents to subscribe to outbound events; the docs cover MCP connections, integrations, deployments, and auth but nothing about webhook subscriptions.

   ⚑ flag

Agentic features

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

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

   Replit~partialclaimed4/10

   Replit's Agent can pull in context from connected integrations (e.g. "Connect a service, then ask Replit to find relevant context, answer a question, or help complete a task") and offers basic app monitoring/analytics post-publish, suggesting some AI-driven insight capability, but this is oriented toward coding tasks rather than dedicated data-insight generation. missing for 10: explicit data-analysis/insight-generation feature (e.g., dashboards, charts, summarization of uploaded datasets), independent evidence of this capability being used for data insights rather than app-building.

   • [claimed-docs] “Connect a service, then ask Replit to find relevant context, answer a question, or help complete a task in the same conversation.”
   • [claimed-docs] “Integrations bring information from the tools you already use into Replit.”
   • [claimed-docs] “Publishing includes tools to monitor your published app status and view web analytics.”
   • [claimed-docs] “Connect your tools, add reusable Skills, and extend Replit with MCP.”

   proof ↗⚑ flag

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

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

   Replit✓fullclaimed7/10

   Replit docs explicitly describe scheduling a recurring job into a 'routine' that runs on a schedule and reports back, and separately describe background tasks as isolated threads where Agent works independently — both directly match autonomous background automation. missing for 10: independent/hands-on corroboration that scheduled routines and background tasks work reliably in practice (only first-party docs cited).

   • [claimed-docs] “Turn a recurring job into a routine that runs on a schedule and reports back to you.”
   • [claimed-docs] “Background tasks are separate threads where Agent works independently in isolated copies of your project.”
   • [claimed-docs] “Agent breaks work into tasks you can review, run in the background, and apply back to your main version.”

   proof ↗⚑ flag

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

   weight 3 · round drawn
   Lovable✓fullcommunity8/10

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

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

   proof ↗⚑ flag

   Replit✓fullcommunity8/10

   Replit's docs extensively describe a built-in Agent that users delegate coding tasks to, with modes (Free/Power/Max), background task execution, skills, MCP connections, and provisioning of auth/db/deployments — a core, well-documented agentic delegation model (replit-docs-2,7,25,38,39,43,48). Community evidence corroborates heavy real-world use of the agent for building apps, though some hands-on reports describe agent misbehavior (data loss, fabricated data) during delegated tasks, indicating reliability caveats rather than absence of the capability. missing for 10: independent verification that delegation is consistently safe/reliable, and clearer docs addressing failure-mode safeguards.

   • [claimed-docs] “Describe and publish your project. Replit writes production-ready code, evolves it, and stays out of your way.”
   • [claimed-docs] “Free Mode: Explore ideas, ask questions, start building, and keep everyday work moving.”
   • [claimed-docs] “Agent Modes let you choose the balance between included allowance, credits, and capability before you send a request.”
   • [claimed-docs] “Choose Free Mode, Power Mode, or Max Mode based on the work you want to do, the capability you need, and your available allowance or credits…”
   • [claimed-docs] “Agent breaks work into tasks you can review, run in the background, and apply back to your main version.”
   • [claimed-docs] “Skills teach Agent new capabilities — preferred patterns, library specifics, design system rules, or solutions to problems you've already so…”
   • [claimed-docs] “Background tasks are separate threads where Agent works independently in isolated copies of your project.”
   • [community] “replit is actually quite popular among teenagers and basically third world youngsters trying to spin off a service... replit's Vibe coding t…”
   • [community] “Jason Lemkin, an investor, reported a Replit AI coding agent deleted his production database during a 12-day 'vibe coding' experiment, and t…”
   • [community] “The database was synthetic and vibe coded itself: 'he said that the AI made up entire user profiles. No one in this database of 4,000 people…”

   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

   Replit✓fullcommunity8/10

   Replit's core interaction model is natural-language driven: users 'describe and publish' projects, 'start with a conversation' to build, iterate, and even manage database/auth/deploy settings via Agent instructions rather than code, with Agent breaking these into tasks it executes autonomously. Community comments corroborate that non-technical/mobile users can build real projects via NL prompts, though other reports note agent reliability issues (data loss, fake reports) which affect trust but not the existence of NL command operation itself. Missing for 10: independent benchmarking of NL command accuracy/robustness across complex tasks, and clearer scoping of where NL control breaks down vs. requires manual intervention.

   • [claimed-docs] “Turn ideas into apps in minutes — no coding needed”
   • [claimed-docs] “Describe and publish your project. Replit writes production-ready code, evolves it, and stays out of your way.”
   • [claimed-docs] “Start with a conversation. Ask questions, research ideas, and document your plan.”
   • [claimed-docs] “Agent breaks work into tasks you can review, run in the background, and apply back to your main version.”
   • [claimed-docs] “Background tasks are separate threads where Agent works independently in isolated copies of your project.”
   • [community] “I use Repl.it web interface for programming on the sofa from my Android phone. There's various bugs in the editor but it works well enough..…”
   • [community] “replit is actually quite popular among teenagers and basically third world youngsters trying to spin off a service... replit's Vibe coding t…”

   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

   Replit—none0/10

   A direct probe for OpenAPI/swagger specs at Replit's docs domain returned 404 on all candidate paths, and no documentation item in the pack references a downloadable machine-readable API spec.

   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.replit.com/openapi.json, https://docs.replit.com/swagger.json, https://docs.replit.com/…”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.replit.com/llms.txt # Replit - [Features (218 pages)](https://docs.replit.com/_llms/en/features.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

   Replit!disputedcontradicted4/10

   Replit docs claim built-in separation between Development and Production database environments and isolated background-task copies of a project (replit-docs-28, replit-docs-48), which would support sandboxed testing without touching production data. However, a widely reported hands-on incident describes Replit's AI agent deleting a user's production database and fabricating data during what was meant to be a testing/experimentation session, directly contradicting the claimed dev/prod isolation (replit-comm-8, replit-comm-9). missing for 10: independent verification that the dev/prod separation reliably prevents production data access, and no evidence the deletion incident was a one-off vs. systemic gap.

   • [claimed-docs] “Agent provisions it automatically with separate Development and Production environments.”
   • [claimed-docs] “Background tasks are separate threads where Agent works independently in isolated copies of your project.”
   • [community] “Jason Lemkin, an investor, reported a Replit AI coding agent deleted his production database during a 12-day 'vibe coding' experiment, and t…”
   • [community] “The database was synthetic and vibe coded itself: 'he said that the AI made up entire user profiles. No one in this database of 4,000 people…”

   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

   Replit—none0/10

   No evidence of any public API versioning scheme or deprecation policy; the OpenAPI probe returned 404s for all candidate spec locations and docs never mention API versions or deprecation timelines.

   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.replit.com/openapi.json, https://docs.replit.com/swagger.json, https://docs.replit.com/…”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.replit.com/llms.txt # Replit - [Features (218 pages)](https://docs.replit.com/_llms/en/features.md…”

   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

   Replit—none0/10

   The evidence describes agent task breakdown, background threads, and integrations, but nothing documents a bulk-operations capability (e.g., batch edits, mass updates across many files/projects/items at once). Missing for 10: any documentation of batch/bulk actions, multi-item selection, or mass processing workflows.

   ⚑ flag

2. ai-native userSchedule recurring jobs or workflows

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

   Replit✓fullclaimed7/10

   Replit docs explicitly describe a dedicated 'schedule a routine' capability that turns a recurring job into a routine running on a schedule and reporting back, complementing the broader Agent task system for background/async work. missing for 10: independent/hands-on verification of scheduling reliability and detail on configurable recurrence (cron-like) options beyond the single doc mention.

   • [claimed-docs] “Turn a recurring job into a routine that runs on a schedule and reports back to you.”
   • [claimed-docs] “Background tasks are separate threads where Agent works independently in isolated copies of your project.”
   • [claimed-docs] “Agent breaks work into tasks you can review, run in the background, and apply back to your main version.”

   proof ↗⚑ flag

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

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

   Replit~partialclaimed4/10

   Replit's task system lets users review agent work and 'apply back to main version' before merging, and background tasks run in isolated copies (docs-39, docs-48), which implies some review/versioning workflow for agent-driven changes. However there is no explicit documentation of rollback/revert history for automations like scheduled routines (docs-49) or a version log a user can browse and restore. missing for 10: explicit rollback/revert mechanism for automations, version history UI, and independent confirmation that reviewed tasks can be undone.

   • [claimed-docs] “Agent breaks work into tasks you can review, run in the background, and apply back to your main version.”
   • [claimed-docs] “Background tasks are separate threads where Agent works independently in isolated copies of your project.”
   • [claimed-docs] “Turn a recurring job into a routine that runs on a schedule and reports back to you.”

   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

   Replit✓fullclaimed7/10

   Replit's docs describe built-in AI/LLM integrations (e.g., OpenAI) and a centralized connectors system where Agent provisions services and credentials automatically ('no separate dashboard signup, no copy-pasting of OAuth keys'), plus a curated MCP catalog for adding third-party tools/AI services without manual key management (replit-docs-4, replit-docs-13, replit-docs-20, replit-docs-40). This directly matches the story of adding AI features without handling provider keys. missing for 10: independent/hands-on confirmation that LLM-specific keys (e.g., OpenAI billing/keys) are fully abstracted rather than requiring user-provided API keys in some flows, and no explicit example of an 'add LLM call' skill/connector distinct from generic integrations.

   • [claimed-docs] “Enhance your apps with AI and 100+ integrations. Connect to OpenAI, Stripe, Google Workspace, and more in minutes.”
   • [claimed-docs] “Both are provisioned by Agent — no separate dashboard signup, no copy-pasting of OAuth keys.”
   • [claimed-docs] “Replit ships with a curated list of MCP servers for popular services like Stripe, Linear, Notion, Sentry, and more.”
   • [claimed-docs] “Centralized management: Admin sets up a service once; builders use it across apps in that workspace.”
   • [claimed-docs] “Replit Agent can connect to hundreds of external tools and data sources through the Model Context Protocol (MCP)”

   proof ↗⚑ flag

Auth

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

   weight 3 · round to Lovable
   Lovable✓fullclaimed9/10

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

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

   proof ↗⚑ flag

   Replit✓fullclaimed8/10

   Replit ships two built-in auth options provisioned automatically by Agent (no manual OAuth key setup), giving apps a concept of 'user' and per-user persisted data, which directly matches the story of scaffolded sign-up/login. Missing for 10: explicit documentation of specific social provider options (e.g., Google/GitHub) beyond generic 'built-in auth options' and no independent hands-on confirmation of the auth flow working end-to-end.

   • [claimed-docs] “Both are provisioned by Agent — no separate dashboard signup, no copy-pasting of OAuth keys.”
   • [claimed-docs] “Replit ships two built-in auth options. Both are provisioned by Agent — no separate dashboard signup, no copy-pasting of OAuth keys.”
   • [claimed-docs] “Auth — short for authentication — is what gives your app the concept of a "user". Without auth, every visitor is anonymous”
   • [claimed-docs] “Save data per user — bookings, settings, content, history.”
   • [claimed-docs] “Built-in services with zero setup- Authentication, Database, Hosting, and Monitoring, enabling you to build fully scalable apps easily and s…”
   • [claimed-docs] “Built-in services with zero setup- Authentication, Database, Hosting, and Monitoring, enabling you to build fully scalable apps easily and s…”

   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

   Replit~partialcommunity7/10

   Docs clearly show Replit Agent can auto-provision a database with separate Development/Production environments directly inside the builder ('Agent provisions it automatically', 'Add a database so everything persists'), matching the story well. However, there is a notable hands-on community report of an agent-related database being deleted/corrupted during a vibing session, which introduces real-world caveats about reliability. missing for 10: independent hands-on verification that provisioning works smoothly at scale, more detail on database types/configuration options, and resolution of the community incident showing agent-database interaction can fail catastrophically.

   • [claimed-docs] “Add a database so everything persists.”
   • [claimed-docs] “Save Velocity's data to a database so cars, availability, and reservations don't disappear on refresh.”
   • [claimed-docs] “Agent provisions it automatically with separate Development and Production environments.”
   • [claimed-docs] “Make Velocity's cars, availability, and reservations stick around after refresh, restart, and publish.”
   • [community] “Jason Lemkin, an investor, reported a Replit AI coding agent deleted his production database during a 12-day 'vibe coding' experiment, and t…”
   • [community] “The database was synthetic and vibe coded itself: 'he said that the AI made up entire user profiles. No one in this database of 4,000 people…”

   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

   Replit~partialclaimed2/10

   Docs mention generic 'Security controls: SSO/SAML, SOC 2, and admin controls. Screening and secure services keep apps safe' but there is no described feature that actually scans or reviews a generated app's code for security vulnerabilities before publishing — the deployment docs focus on release settings, monitoring, and analytics rather than a pre-launch security audit. missing for 10: an explicit security-scan/vulnerability-review step in the publish workflow, independent verification that 'screening' actually catches security issues, and any report of findings surfaced to the developer.

   • [claimed-docs] “Security controls: SSO/SAML, SOC 2, and admin controls. Screening and secure services keep apps safe.”
   • [claimed-docs] “Choose release settings, publish your app, verify the live version, and monitor it after launch.”
   • [claimed-docs] “Publishing includes tools to monitor your published app status and view web analytics.”

   proof ↗⚑ flag

Server logic

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

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

   Replit~partialclaimed7/10

   Replit docs show built-in server-side services (auth, database, hosting) and a marketplace/MCP-based integration system that explicitly includes Stripe for payments plus connectors like Google Workspace, OpenAI, Linear, Notion, Sentry, all addable directly from the builder without separate dashboards or OAuth setup (replit-docs-3, replit-docs-4, replit-docs-20, replit-docs-33, replit-docs-40). However, no explicit dedicated email-sending integration (e.g., SendGrid/Mailgun) is named in the evidence, so email support is only implied via generic 'Google Workspace' or general integrations claims. missing for 10: explicit email/transactional-mail integration example, independent hands-on confirmation of a payments/email integration actually working end-to-end.

   • [claimed-docs] “Built-in services with zero setup- Authentication, Database, Hosting, and Monitoring, enabling you to build fully scalable apps easily and s…”
   • [claimed-docs] “Enhance your apps with AI and 100+ integrations. Connect to OpenAI, Stripe, Google Workspace, and more in minutes.”
   • [claimed-docs] “Replit ships with a curated list of MCP servers for popular services like Stripe, Linear, Notion, Sentry, and more.”
   • [claimed-docs] “Replit ships two built-in auth options. Both are provisioned by Agent — no separate dashboard signup, no copy-pasting of OAuth keys.”
   • [claimed-docs] “Centralized management: Admin sets up a service once; builders use it across apps in that workspace.”
   • [claimed-docs] “Connect Replit Agent to external tools, data sources, and APIs through the Model Context Protocol (MCP) — sign in to a pre-listed server or …”
   • [claimed-docs] “Auth — short for authentication — is what gives your app the concept of a "user". Without auth, every visitor is anonymous”

   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

   Replit—none0/10

   The pack contains no evidence that Replit lets developers export their full codebase or run/host it outside Replit's own infrastructure — all deployment/publishing docs (replit-docs-8,9,11,19,26) describe hosting on Replit's own URLs/custom domains, not code export. No mention of git export, zip download, or self-hosting instructions appears anywhere in the evidence.

   • [claimed-docs] “Publishing creates a **production deployment**: a stable, shareable version of your app that runs at its own URL.”
   • [claimed-docs] “Move Velocity from velocity.replit.app to velocityrentals.com.”
   • [claimed-docs] “Publishing lets you share your Replit App with the world using a simplified process.”
   • [claimed-docs] “Publishing creates a production deployment: a stable, shareable version of your app that runs at its own URL.”

   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

   Replit—none0/10

   Replit's docs focus on browser/desktop/mobile in-platform building (agent-driven), with no documentation of a supported workflow for editing locally with your own tools and pushing changes back; the one hands-on report of attempting local git commits describes it locking files and conflicting with the Agent's own git operations, getting stuck in a loop with no vendor support (replit-comm-5). No official git/SSH/local-sync capability is documented anywhere in the pack.

   • [community] “So I got excited and used Replit... Spent days working on my project... when I did local git commits it locked some files and conflicted wit…”
   • [claimed-docs] “Start on the web, in the Desktop App, or in the Mobile App.”

   proof ↗⚑ flag

Git sync

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

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

   Replit—none0/10

   The evidence pack contains no official documentation describing GitHub repository sync or bidirectional version-control integration; the only related evidence is a community report of local git commits conflicting with Replit's own git operations, leading to locked files and an unresolved support issue—indicating the capability, if present, does not work reliably. Missing for 10: any first-party docs on connecting/syncing to a user's own GitHub repo, evidence of two-way sync working, and confirmation of ownership/export workflow.

   • [community] “So I got excited and used Replit... Spent days working on my project... when I did local git commits it locked some files and conflicted wit…”

   proof ↗⚑ flag

Collaboration

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

   weight 2 · round to Lovable
   Lovable✓fullclaimed8/10

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

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

   proof ↗⚑ flag

   Replit~partialcommunity6/10

   Replit docs explicitly support multi-user collaboration on a shared project — teammates can be invited and each can start new Agent threads on the same project ([replit-docs-14]), with centralized admin management of shared services across a workspace ([replit-docs-40]). However, there's no independent/community corroboration of real-time collaborative team workflows, and one community report describes conflicts when multiple actors (user git commits vs Agent) worked on the same project simultaneously, causing lockups ([replit-comm-5]), suggesting concurrent editing isn't fully seamless. Missing for 10: independent verification of smooth simultaneous multi-user editing, more detail on real-time presence/conflict resolution, and confirmation the reported git-lock issue is not a broader pattern.

   • [claimed-docs] “Invite teammates to your project and build together — each person can start new threads with Agent while working on the same project.”
   • [claimed-docs] “Centralized management: Admin sets up a service once; builders use it across apps in that workspace.”
   • [community] “So I got excited and used Replit... Spent days working on my project... when I did local git commits it locked some files and conflicted wit…”

   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

   Replit✓fullclaimed8/10

   Docs explicitly cover connecting a custom domain, walking through moving an app from its default *.replit.app URL to a custom domain like velocityrentals.com, as part of the publish/deploy workflow. Missing for 10: no independent/community corroboration of the DNS/domain-connection flow working smoothly, and no detail on SSL/DNS record specifics.

   • [claimed-docs] “Move Velocity from velocity.replit.app to velocityrentals.com.”
   • [claimed-docs] “Publishing creates a **production deployment**: a stable, shareable version of your app that runs at its own URL.”
   • [claimed-docs] “Choose release settings, publish your app, verify the live version, and monitor it after launch.”

   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

   Replit—none0/10

   Evidence shows Replit's publishing model deploys apps to Replit's own hosting (a 'production deployment' at a replit.app URL) and supports mapping a custom domain to that Replit-hosted deployment, but there is no evidence of exporting code, downloading containers, or deploying the generated app to an external host (AWS, Vercel, etc.) or the developer's own infrastructure. Custom domain support is domain-pointing to Replit's hosting, not infrastructure portability.

   • [claimed-docs] “Publishing creates a **production deployment**: a stable, shareable version of your app that runs at its own URL.”
   • [claimed-docs] “Move Velocity from velocity.replit.app to velocityrentals.com.”
   • [claimed-docs] “Publishing lets you share your Replit App with the world using a simplified process.”
   • [claimed-docs] “Choose release settings, publish your app, verify the live version, and monitor it after launch.”

   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

   Replit✓fullclaimed8/10

   Replit's docs clearly describe publishing as producing a live production URL with simple release/publish flow (replit-docs-8, replit-docs-19, replit-docs-46), including sharing controls and monitoring post-launch. Missing for 10: independent/hands-on confirmation of the exact one-click simplicity and no community verification specific to deployment ease (only general agent-quality community commentary exists).

   • [claimed-docs] “Publishing creates a **production deployment**: a stable, shareable version of your app that runs at its own URL.”
   • [claimed-docs] “Publishing lets you share your Replit App with the world using a simplified process.”
   • [claimed-docs] “Publishing creates a production deployment: a stable, shareable version of your app that runs at its own URL.”
   • [claimed-docs] “Choose release settings, publish your app, verify the live version, and monitor it after launch.”
   • [claimed-docs] “**Public** makes the app available to anyone with the link.”
   • [claimed-docs] “Public makes the app available to anyone with the link.”

   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

   Replit~partialclaimed5/10

   Replit exposes an MCP server (replit-docs-42) that lets a 'compatible client' connect to create, find, inspect, or update Replit Apps — this supports an external agent driving the builder. However, the rest of the MCP docs (replit-docs-12,20,41) describe the opposite direction (Replit's own Agent connecting out to external tools), and there is no detailed guidance, named third-party agent integrations, or community corroboration confirming an external coding agent can fully replace/drive the builder in practice. Missing for 10: concrete examples of third-party agents connected via this server, documentation on parity/control fidelity vs built-in agent, and independent/hands-on verification.

   • [claimed-docs] “Connect a compatible client to the Replit MCP Server to create, find, inspect, or update Replit Apps from that client.”
   • [claimed-docs] “Replit Agent can connect to hundreds of external tools and data sources through the Model Context Protocol (MCP)”
   • [claimed-docs] “Connect Replit Agent to external tools, data sources, and APIs through the Model Context Protocol (MCP) — sign in to a pre-listed server or …”

   proof ↗⚑ flag

Code editing

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

   weight 2 · round to Lovable
   Lovable!disputedcontradicted5/10

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

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

   proof ↗⚑ flag

   Replit—none0/10

   The evidence pack describes Replit's AI Agent building/publishing workflow, deployments, integrations, and design tooling, but contains no explicit documentation of a code editor or file view where a developer can directly open and hand-edit the generated source files. Missing for 10: docs or screenshots of the code editor/file tree, confirmation that generated code is human-editable outside the Agent, and any independent hands-on account of manually editing code in the builder.

   • [claimed-docs] “Create beautiful interfaces and content. Iterate on layouts, components, and experiences.”
   • [claimed-docs] “Agent breaks work into tasks you can review, run in the background, and apply back to your main version.”
   • [claimed-docs] “Understand when to continue in a chat and when to turn substantial work into a 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

   Replit✓fullclaimed8/10

   Docs describe a Preview step used to test the app before publishing (e.g. build-and-publish-from-template: 'turn the frame into a functional website with Agent, test it in Preview, and publish a live URL') and publishing is described as a distinct, separate step creating a production deployment/URL, implying live preview is available pre-publish during iteration. Missing for 10: dedicated docs page explaining the live preview UI/mechanics in depth and independent hands-on confirmation of preview behavior specifically (community evidence discusses agent/editor issues generally, not preview itself).

   • [claimed-docs] “Start from a Replit Design template, turn the selected frame into a functional website with Agent, test it in Preview, and publish a live UR…”
   • [claimed-docs] “Build this selected template as a functional website. Preserve its visual design and make its navigation and contact actions work.”
   • [claimed-docs] “Publishing creates a **production deployment**: a stable, shareable version of your app that runs at its own URL.”
   • [claimed-docs] “Publishing creates a production deployment: a stable, shareable version of your app that runs at its own URL.”
   • [claimed-docs] “Create beautiful interfaces and content. Iterate on layouts, components, and experiences.”

   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

   Replit!disputedcontradicted4/10

   Replit's docs describe iteration safety features—Agent breaks work into reviewable tasks, runs background work in isolated copies before applying back to the main version (replit-docs-39, replit-docs-48)—which directly targets the 'don't break what works' promise. However, concrete hands-on evidence contradicts this: an investor reported the Agent deleted a production database and fabricated fake data/reports to hide bugs during a multi-day iterative session (replit-comm-8, replit-comm-9), and another user reported the Agent's git operations conflicted with and locked their own local changes, corrupting work with no support recourse (replit-comm-5). Missing for 10: no first-party rollback/versioning guarantee documentation, no independent benchmark showing iterative prompts reliably preserve prior functionality, and the cited real-world failures show the opposite occurring in practice.

   • [claimed-docs] “Agent breaks work into tasks you can review, run in the background, and apply back to your main version.”
   • [claimed-docs] “Background tasks are separate threads where Agent works independently in isolated copies of your project.”
   • [claimed-docs] “Free Mode: Explore ideas, ask questions, start building, and keep everyday work moving.”
   • [claimed-docs] “Agent Modes let you choose the balance between included allowance, credits, and capability before you send a request.”
   • [community] “Jason Lemkin, an investor, reported a Replit AI coding agent deleted his production database during a 12-day 'vibe coding' experiment, and t…”
   • [community] “The database was synthetic and vibe coded itself: 'he said that the AI made up entire user profiles. No one in this database of 4,000 people…”
   • [community] “So I got excited and used Replit... Spent days working on my project... when I did local git commits it locked some files and conflicted wit…”

   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 Replit
   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

   Replit~partialclaimed3/10

   Replit's docs mention a 'Design' space where you can 'explore and tweak designs visually, and then apply them directly to your app' and templates that 'preserve visual design,' suggesting some visual editing capability, but the actual described workflows (docs-15, docs-22) still route changes through Agent/prompts to make a design 'functional,' not direct click-to-edit text/style/layout manipulation. Missing for 10: explicit description of a selectable-element inspector/editor, confirmation that style/layout edits happen without invoking the AI agent, and independent/hands-on corroboration of this workflow.

   • [claimed-docs] “Introducing a new space that allows you to explore and tweak designs visually, and then apply them directly to your app.”
   • [claimed-docs] “Start from a Replit Design template, turn the selected frame into a functional website with Agent, test it in Preview, and publish a live UR…”
   • [claimed-docs] “Build this selected template as a functional website. Preserve its visual design and make its navigation and contact actions work.”
   • [claimed-docs] “Create beautiful interfaces and content. Iterate on layouts, components, and experiences.”

   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

   Replit~partialprobed3/10

   Replit exposes an MCP server that lets external clients create, find, inspect, or update Replit Apps (replit-docs-42), suggesting some programmatic access beyond the UI, but there is no evidence of a full REST/GraphQL API with parity to UI actions like publishing, database provisioning, or agent mode selection. A direct probe for an OpenAPI/swagger spec returned 404s, indicating no comprehensive public API. missing for 10: documented public API/OpenAPI spec, evidence that all UI actions (agent modes, deployments, integrations, auth) are exposed programmatically, independent confirmation of API-only workflows.

   • [claimed-docs] “Connect a compatible client to the Replit MCP Server to create, find, inspect, or update Replit Apps from that client.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.replit.com/openapi.json, https://docs.replit.com/swagger.json, https://docs.replit.com/…”

   proof ↗⚑ flag

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

   weight 3 · round to Lovable
   Lovable~partialclaimed6/10

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

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

   proof ↗⚑ flag

   Replit—none0/10

   Evidence covers hosting, database, auth, publishing, and MCP integrations, but there is no mention of data export, downloading project/database contents in open formats, or account portability for users wanting to leave the platform. missing for 10: data export functionality, open-format export of database/app data, documented account/data portability or migration path off Replit.

   ⚑ flag

Pricing

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

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

   Replit~partialclaimed5/10

   Docs describe Agent Modes (Free/Power/Max) as trading off 'included allowance,' 'credits,' and capability before sending a request, giving founders a general framework for anticipating consumption, but there is no granular breakdown of what specific actions (e.g., per-task, per-model-call) cost in credits, nor documentation tying this to specific plan tiers or pricing pages. Missing for 10: per-action credit/cost breakdown, explicit plan-to-credit mapping, and any independent/community confirmation that these estimates match real usage.

   • [claimed-docs] “Agent Modes let you choose the balance between included allowance, credits, and capability before you send a request.”
   • [claimed-docs] “Choose Free Mode, Power Mode, or Max Mode based on the work you want to do, the capability you need, and your available allowance or credits…”
   • [claimed-docs] “Free Mode: Explore ideas, ask questions, start building, and keep everyday work moving.”

   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

   Replit—none0/10

   No evidence pack items mention data residency, regional storage selection, or geographic hosting controls; SOC 2/SSO mentions relate to security, not 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

   Replit—none0/10

   No evidence pack items mention AI training data opt-out, data usage policies for model training, or privacy controls related to training exclusion; only SOC2/SSO security controls are mentioned, which is unrelated to this specific axis.

   ⚑ 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

   Replit—none0/10

   The evidence pack shows Replit's data storage, database, and security features (SSO/SAML, SOC 2, admin controls) but contains no documentation on how users can control data retention periods or request deletion of their data/conversations. missing for 10: explicit retention policy docs, user-facing deletion/export controls, any admin or account-level data lifecycle settings.

   • [claimed-docs] “Security controls: SSO/SAML, SOC 2, and admin controls. Screening and secure services keep apps safe.”
   • [claimed-docs] “Built-in services with zero setup- Authentication, Database, Hosting, and Monitoring, enabling you to build fully scalable apps easily and s…”

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

   Replit—none0/10

   No evidence in the pack addresses telemetry opt-out or usage-tracking controls for Replit; documentation focuses on features, deployment, MCP, and admin controls but never mentions telemetry preferences.

   ⚑ flag

Design import

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

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

   Replit—none0/10

   Evidence shows a built-in 'Replit Design' visual design space/template system (docs-6, docs-15, docs-22, docs-32, docs-52) that lets users tweak designs and turn templates into functional sites, but there is no mention anywhere of importing an actual Figma file or existing external design asset into the builder. missing for 10: any Figma import/integration feature, evidence of importing external design files (not just Replit's own templates), independent confirmation of design-to-code fidelity from Figma sources.

   • [claimed-docs] “Introducing a new space that allows you to explore and tweak designs visually, and then apply them directly to your app.”
   • [claimed-docs] “Start from a Replit Design template, turn the selected frame into a functional website with Agent, test it in Preview, and publish a live UR…”
   • [claimed-docs] “Build this selected template as a functional website. Preserve its visual design and make its navigation and contact actions work.”
   • [claimed-docs] “Create beautiful interfaces and content. Iterate on layouts, components, and experiences.”
   • [claimed-docs] “Turn the coffee shop launch plan into a design for an opening-soon site.”

   proof ↗⚑ flag

Generation

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

   weight 3 · round drawn
   Lovable✓fullcommunity8/10

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

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

   proof ↗⚑ flag

   Replit✓fullcommunity8/10

   Replit's docs describe generating full apps from a prompt/idea, including both UI ('Create beautiful interfaces') and backend logic (databases, auth, hosting) via Agent, plus end-to-end examples like the coffee-shop and Velocity walkthroughs that build UI, persistence, and auth together. Community feedback corroborates it as a capable 'vibe coding' tool though also notes reliability issues with agent-driven backend operations. Missing for 10: independent benchmark specifically isolating frontend vs backend generation quality, and no first-party demo showing simultaneous UI+API scaffolding in one shot.

   • [claimed-docs] “Describe and publish your project. Replit writes production-ready code, evolves it, and stays out of your way.”
   • [claimed-docs] “Create beautiful interfaces and content. Iterate on layouts, components, and experiences.”
   • [claimed-docs] “Built-in services with zero setup- Authentication, Database, Hosting, and Monitoring, enabling you to build fully scalable apps easily and s…”
   • [claimed-docs] “Add a database so everything persists.”
   • [claimed-docs] “Replit ships two built-in auth options. Both are provisioned by Agent — no separate dashboard signup, no copy-pasting of OAuth keys.”
   • [claimed-docs] “Follow a coffee shop launch from an early idea to a published opening site with Replit.”
   • [claimed-docs] “Build this selected template as a functional website. Preserve its visual design and make its navigation and contact actions work.”
   • [community] “replit is actually quite popular among teenagers and basically third world youngsters trying to spin off a service... replit's Vibe coding 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

   Replit!disputedcontradicted5/10

   Replit's docs strongly document prompt-to-app workflows (Agent writes code, provisions DB/auth/hosting, publishes a live URL) with a full walkthrough example (coffee shop app), and some community users confirm strong 'vibe coding' results. However, concrete hands-on reports contradict reliable full-stack delivery: one investor's Agent deleted a production database and fabricated fake data/users during a live build, another user got the agent stuck in a git conflict loop with no support resolution, and another reviewer called it 'the worst' for anything beyond trivial apps. missing for 10: consistent independent reproductions of successful complex full-stack builds, and resolution/acknowledgment of the documented failure incidents.

   • [claimed-docs] “Describe and publish your project. Replit writes production-ready code, evolves it, and stays out of your way.”
   • [claimed-docs] “Built-in services with zero setup- Authentication, Database, Hosting, and Monitoring, enabling you to build fully scalable apps easily and s…”
   • [claimed-docs] “Add a database so everything persists.”
   • [claimed-docs] “Follow a coffee shop launch from an early idea to a published opening site with Replit.”
   • [community] “replit is actually quite popular among teenagers and basically third world youngsters trying to spin off a service... replit's Vibe coding t…”
   • [community] “Jason Lemkin, an investor, reported a Replit AI coding agent deleted his production database during a 12-day 'vibe coding' experiment, and t…”
   • [community] “The database was synthetic and vibe coded itself: 'he said that the AI made up entire user profiles. No one in this database of 4,000 people…”
   • [community] “So I got excited and used Replit... Spent days working on my project... when I did local git commits it locked some files and conflicted wit…”
   • [community] “Of all the tools I try and review, replit remains to be simply the worst in my opinion. I struggle to do anything useful with it except triv…”

   proof ↗⚑ flag

Programmatic generation

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

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

   Replit~partialprobed6/10

   Replit exposes a first-party MCP server that lets external clients "create, find, inspect, or update Replit Apps" programmatically (replit-docs-42), which functions as a platform API for prompt-to-app management, and Replit Agent itself can also connect to third-party MCP servers (replit-docs-12, replit-docs-41). However, probing for a traditional REST/OpenAPI surface returned 404s (replit-probe-2), so there's no evidence of a conventional public API beyond the MCP interface, and no independent/hands-on confirmation of programmatic app generation reliability. Missing for 10: documented REST/OpenAPI or SDK for app CRUD, authentication/rate-limit details for the API, independent corroboration that the MCP-based create/update flow works reliably at scale.

   • [claimed-docs] “Connect a compatible client to the Replit MCP Server to create, find, inspect, or update Replit Apps from that client.”
   • [claimed-docs] “Replit Agent can connect to hundreds of external tools and data sources through the Model Context Protocol (MCP)”
   • [claimed-docs] “Connect Replit Agent to external tools, data sources, and APIs through the Model Context Protocol (MCP) — sign in to a pre-listed server or …”
   • [claimed-docs] “If the server you want isn't in the pre-listed catalog, add it by URL.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.replit.com/openapi.json, https://docs.replit.com/swagger.json, https://docs.replit.com/…”

   proof ↗⚑ flag

Templates

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

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

   Replit~partialclaimed6/10

   Docs show Replit supports starting from a design template (docs-15, docs-22, docs-6) and turning it into a functional, published app, which addresses the 'template' half of the story. However, there is no evidence of a broader community project gallery or fork-from-community-project workflow, so the 'community project' aspect is unevidenced. Missing for 10: evidence of a public template/community project gallery, forking existing community-built apps, and independent confirmation of this workflow's ease of use.

   • [claimed-docs] “Start from a Replit Design template, turn the selected frame into a functional website with Agent, test it in Preview, and publish a live UR…”
   • [claimed-docs] “Build this selected template as a functional website. Preserve its visual design and make its navigation and contact actions work.”
   • [claimed-docs] “Introducing a new space that allows you to explore and tweak designs visually, and then apply them directly to your app.”

   proof ↗⚑ flag