Lovable vs Floot

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

   Floot✓fullprobed8/10

   Floot serves a live llms.txt (HTTP 200) and an llms-full.txt with agent-oriented documentation of its capabilities, confirmed by direct probes. missing for 10: independent third-party confirmation that agents actually consume and act on these docs successfully, and docs.md/openapi endpoints return 404 suggesting the agent-doc surface is limited to llms.txt only.

   • [probe] “PROBE llms.txt: HTTP 200 at https://floot.com/llms.txt # Floot > Floot turns a plain-language description into a real, deployed full-stack …”
   • [claimed-docs] “point at an element or annotate a screenshot for the assistant to pick up”
   • [probe] “PROBE docs-md: HTTP 404 at https://floot.com/docs.md”
   • [probe] “PROBE openapi: all candidate paths 404 (https://floot.com/openapi.json, https://floot.com/swagger.json, https://floot.com/api/openapi.json, …”

   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

   Floot—none0/10

   Floot is a chat-based/MCP-driven app builder with no evidence of a CLI, API, or headless mode for CI/automation pipelines; MCP integration is for interactive AI clients (Cursor, VS Code, Zed), not headless CI execution. No mention of scripted builds, CI/CD triggers, or non-interactive automation. Missing for 10: CLI or SDK for scripted invocation, CI/CD pipeline documentation, headless build/deploy commands, API endpoints for automation.

   ⚑ flag

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

   weight 3 · round to Lovable
   Lovable✓fullclaimed8/10

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

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

   proof ↗⚑ flag

   Floot—none0/10

   All evidence describes Floot exposing itself as an MCP server that other clients (Cursor, VS Code, Zed) can connect to and use its tools (get_logs, query_database, etc.) — the reverse direction of this story. There is no evidence that a user can plug external MCP servers into Floot so Floot's own AI can call their tools.

   • [claimed-docs] “Add Floot to Cursor, VS Code, Zed, or any client that supports remote MCP servers”
   • [claimed-docs] “get_logs — the first step for any 500, blank page, or failed request.”
   • [claimed-docs] “query_database for reads, execute_sql for writes and migrations, pull_database_schema to regenerate typed helpers.”
   • [probe] “official MCP server documented at https://floot.com/docs/integrations/other-mcp-clients”

   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

   Floot✓fullprobed7/10

   Floot documents an official remote MCP server that can be added to Cursor, VS Code, Zed, or any MCP-compatible client, with concrete tool capabilities (get_logs, query_database, execute_sql, create_checkpoint, generate_image) exposed via that server. This is first-party documentation only, with no independent/hands-on corroboration of the MCP connection working in practice. Missing for 10: independent or community verification of the MCP server working end-to-end, and more detail on authentication/setup reliability.

   • [claimed-docs] “Add Floot to Cursor, VS Code, Zed, or any client that supports remote MCP servers”
   • [claimed-docs] “get_logs — the first step for any 500, blank page, or failed request.”
   • [claimed-docs] “query_database for reads, execute_sql for writes and migrations, pull_database_schema to regenerate typed helpers.”
   • [claimed-docs] “create_checkpoint labels a point you can revert to from the Checkpoint panel in your project view.”
   • [claimed-docs] “generate_image writes AI images into the project.”
   • [probe] “official MCP server documented at https://floot.com/docs/integrations/other-mcp-clients”

   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

   Floot—none0/10

   Floot is a chat/browser-based app builder that offers an MCP server for connecting external AI clients, but there is no evidence of an official CLI tool for AI-native workflows; all evidence points to MCP integration and web-based chat, not a CLI. Missing for 10: any mention of a CLI binary, npm/pip install, or command-line docs.

   • [claimed-docs] “Add Floot to Cursor, VS Code, Zed, or any client that supports remote MCP servers”
   • [probe] “official MCP server documented at https://floot.com/docs/integrations/other-mcp-clients”

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

   Floot~partialprobed7/10

   Floot documents a first-party MCP server exposing concrete tools (get_logs, query_database, execute_sql, create_checkpoint, generate_image) that let an AI client drive the product programmatically, which directly serves the AI-native persona. However, probes show no conventional public REST/OpenAPI API (openapi.json/swagger.json all 404, docs.md 404), so the 'documented public API' story is only satisfied via the MCP protocol rather than a broader API surface. Missing for 10: a traditional REST/OpenAPI-documented API or SDK, and independent confirmation of MCP tool reliability beyond vendor docs.

   • [claimed-docs] “Add Floot to Cursor, VS Code, Zed, or any client that supports remote MCP servers”
   • [claimed-docs] “get_logs — the first step for any 500, blank page, or failed request.”
   • [claimed-docs] “query_database for reads, execute_sql for writes and migrations, pull_database_schema to regenerate typed helpers.”
   • [claimed-docs] “create_checkpoint labels a point you can revert to from the Checkpoint panel in your project view.”
   • [claimed-docs] “generate_image writes AI images into the project.”
   • [probe] “official MCP server documented at https://floot.com/docs/integrations/other-mcp-clients”
   • [probe] “PROBE openapi: all candidate paths 404 (https://floot.com/openapi.json, https://floot.com/swagger.json, https://floot.com/api/openapi.json, …”
   • [probe] “PROBE docs-md: HTTP 404 at https://floot.com/docs.md”

   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

   Floot—none0/10

   No evidence Floot supports issuing scoped or least-privilege API credentials/tokens for agents; MCP integration docs describe tool capabilities (query_database, execute_sql, etc.) but nothing about credential scoping, permission levels, or least-privilege access control for agents. missing for 10: any mention of API keys, token scoping, permission tiers, or credential management for agent access.

   • [claimed-docs] “query_database for reads, execute_sql for writes and migrations, pull_database_schema to regenerate typed helpers.”
   • [probe] “official MCP server documented at https://floot.com/docs/integrations/other-mcp-clients”

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

   Floot—none0/10

   Floot exposes an MCP server with tool functions (get_logs, query_database, execute_sql, etc.) but there is no evidence of official language SDKs (e.g., npm/pip packages) or an OpenAPI spec for developers to build against programmatically; probes for openapi.json/swagger.json all 404.

   • [probe] “PROBE openapi: all candidate paths 404 (https://floot.com/openapi.json, https://floot.com/swagger.json, https://floot.com/api/openapi.json, …”
   • [probe] “PROBE docs-md: HTTP 404 at https://floot.com/docs.md”
   • [claimed-docs] “query_database for reads, execute_sql for writes and migrations, pull_database_schema to regenerate typed helpers.”

   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

   Floot—none0/10

   No evidence pack item mentions webhooks, event subscriptions, or any outbound notification/event system that AI-native users could subscribe to; the docs cover database, logs, images, mobile apps, and MCP tooling but nothing about webhooks.

   ⚑ flag

Agentic features

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

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

   Floot—none0/10

   Floot's docs show built-in analytics tracking (page views, traffic sources, trends) and AI tools that can query/execute against the app's database, but there is no evidence the AI surfaces proactive insights or suggestions derived from that data back to the user — the query/execute tools are for development/debugging, not analytical insight generation.

   • [claimed-docs] “Built-in visitor tracking: page views, traffic sources, and trends.”
   • [claimed-docs] “query_database for reads, execute_sql for writes and migrations, pull_database_schema to regenerate typed helpers.”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   Lovable—none0/10

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

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

   proof ↗⚑ flag

   Floot—none0/10

   Floot's evidence covers app-building tools (database queries, logs, checkpoints, image generation, MCP integration) but nothing about scheduled tasks, triggers, or autonomous background automations running independently of a chat session. There is no mention of cron-like jobs, webhooks-as-triggers, or agent workflows executing without user interaction.

   ⚑ 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

   Floot✓fullprobed8/10

   Floot's core product is an AI chat assistant that builds, debugs, queries databases, generates images, and manages checkpoints for the app directly from the chat interface, with tool actions like get_logs, query_database, generate_image documented. missing for 10: independent/hands-on corroboration beyond vendor docs, and clearer detail on task complexity/limits the assistant can handle autonomously.

   • [claimed-docs] “build and ship full-stack apps without leaving your AI chat”
   • [claimed-docs] “get_logs — the first step for any 500, blank page, or failed request.”
   • [claimed-docs] “query_database for reads, execute_sql for writes and migrations, pull_database_schema to regenerate typed helpers.”
   • [claimed-docs] “create_checkpoint labels a point you can revert to from the Checkpoint panel in your project view.”
   • [claimed-docs] “point at an element or annotate a screenshot for the assistant to pick up”
   • [claimed-docs] “generate_image writes AI images into the project.”
   • [probe] “PROBE llms.txt: HTTP 200 at https://floot.com/llms.txt # Floot > Floot turns a plain-language description into a real, deployed full-stack …”

   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

   Floot✓fullprobed8/10

   Floot's core product is natural-language chat-based app building ('build and ship full-stack apps without leaving your AI chat', 'turns a plain-language description into a real, deployed full-stack app'), with rich agentic tool support (get_logs, query_database, create_checkpoint, generate_image) operable via NL commands. Missing for 10: independent/hands-on corroboration beyond vendor docs, and no detail on limits of NL command coverage for advanced operations.

   • [claimed-docs] “build and ship full-stack apps without leaving your AI chat”
   • [probe] “PROBE llms.txt: HTTP 200 at https://floot.com/llms.txt # Floot > Floot turns a plain-language description into a real, deployed full-stack …”
   • [claimed-docs] “get_logs — the first step for any 500, blank page, or failed request.”
   • [claimed-docs] “query_database for reads, execute_sql for writes and migrations, pull_database_schema to regenerate typed helpers.”
   • [claimed-docs] “create_checkpoint labels a point you can revert to from the Checkpoint panel in your project view.”
   • [claimed-docs] “generate_image writes AI images into the project.”

   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

   Floot—none0/10

   Direct probes for OpenAPI/Swagger specs all returned 404 at every candidate path, and no documentation mentions a machine-readable API spec for Floot's own platform API.

   • [probe] “PROBE openapi: all candidate paths 404 (https://floot.com/openapi.json, https://floot.com/swagger.json, https://floot.com/api/openapi.json, …”
   • [probe] “PROBE docs-md: HTTP 404 at https://floot.com/docs.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

   Floot—none0/10

   Evidence shows database tools (query_database, execute_sql) and checkpoint/revert features, but nothing describes a separate sandbox/staging environment isolated from production data — checkpoints revert code state, not provide a parallel test database. Missing for 10: any mention of a staging/sandbox database, environment cloning, or explicit separation between test and production data.

   • [claimed-docs] “query_database for reads, execute_sql for writes and migrations, pull_database_schema to regenerate typed helpers.”
   • [claimed-docs] “create_checkpoint labels a point you can revert to from the Checkpoint panel in your project view.”

   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

   Floot—none0/10

   No evidence of any versioned API or documented deprecation policy; OpenAPI probes returned 404 and no changelog/docs mention API versioning or deprecation practices. missing for 10: versioned API documentation, deprecation policy statement, API stability guarantees.

   • [probe] “PROBE openapi: all candidate paths 404 (https://floot.com/openapi.json, https://floot.com/swagger.json, https://floot.com/api/openapi.json, …”
   • [probe] “PROBE docs-md: HTTP 404 at https://floot.com/docs.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

   Floot—none0/10

   Floot's evidence covers single-app database queries/writes (query_database, execute_sql) and other AI-assisted dev tools, but nothing describes bulk operations across many items/records/projects at once as a distinct capability. missing for 10: any documentation of batch/bulk editing, mass updates across records, or multi-item automation workflows.

   • [claimed-docs] “query_database for reads, execute_sql for writes and migrations, pull_database_schema to regenerate typed helpers.”

   proof ↗⚑ flag

2. ai-native userSchedule recurring jobs or workflows

   weight 2 · round drawn
   Lovable—none0/10

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

   ⚑ flag

   Floot—none0/10

   No evidence anywhere in the pack of scheduled/recurring jobs, cron-like automation, or workflow scheduling features; Floot's documented tools cover logs, database queries, checkpoints, image generation, mobile app conversion, and self-hosting but nothing about recurring or scheduled execution.

   ⚑ flag

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

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

   Floot~partialclaimed5/10

   Floot documents a checkpoint system where create_checkpoint labels a revertible point accessible from the Checkpoint panel, covering versioning and rollback of AI-driven changes. However, there is no evidence of a review/diff mechanism to inspect what changed before reverting, nor of a broader automation version history beyond simple checkpoints. Missing for 10: explicit review/diff tooling, multi-version history browsing, and independent confirmation of rollback reliability.

   • [claimed-docs] “create_checkpoint labels a point you can revert to from the Checkpoint panel in your project view.”

   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

   Floot—none0/10

   The evidence shows Floot's builder assistant can call tools like generate_image during app creation, but there is no documentation of end-user apps being able to make LLM calls or run agents with Floot managing the provider API keys on the app's behalf.

   ⚑ 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

   Floot—none0/10

   The evidence pack covers Floot's database, logging, image generation, mobile app conversion, and self-hosting features, but contains no mention of authentication, user sign-up/login scaffolding, or social provider integration. This is a reasonable capability to expect from a full-stack app builder, so its absence is a gap rather than an inapplicable axis.

   ⚑ 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

   Floot✓fullprobed7/10

   Floot documents built-in database tooling (query_database, execute_sql, pull_database_schema) accessible directly through the AI assistant inside the builder, indicating a database is provisioned and wired automatically without leaving the chat/builder. Missing for 10: independent/hands-on confirmation of automatic provisioning flow and details on database type/scaling, and no explicit doc showing the provisioning UX step-by-step.

   • [claimed-docs] “query_database for reads, execute_sql for writes and migrations, pull_database_schema to regenerate typed helpers.”
   • [claimed-docs] “build and ship full-stack apps without leaving your AI chat”
   • [probe] “PROBE llms.txt: HTTP 200 at https://floot.com/llms.txt # Floot > Floot turns a plain-language description into a real, deployed full-stack …”

   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

   Floot—none0/10

   No evidence pack item mentions security review, vulnerability scanning, or pre-launch security audits of generated apps; the docs cover logging, database tools, checkpoints, mobile export, and self-hosting but nothing on security review workflows. Missing for 10: any mention of automated security scanning, vulnerability checks, or a review gate before deployment.

   ⚑ flag

Server logic

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

   weight 2 · round drawn
   Lovable~partialclaimed6/10

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

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

   proof ↗⚑ flag

   Floot~partialclaimed6/10

   Floot's docs show database read/write tools (query_database, execute_sql), built-in email sending/receiving, and other backend-like capabilities exposed to the AI builder, indicating server-side functionality can be added conversationally. However, there is no explicit mention of general-purpose custom server-side functions or third-party payment integrations, which are core parts of this story. Missing for 10: explicit payments integration support, generic server-side function/webhook creation beyond DB and email, and independent verification of these integrations working in practice.

   • [claimed-docs] “query_database for reads, execute_sql for writes and migrations, pull_database_schema to regenerate typed helpers.”
   • [claimed-docs] “Your apps can now send AND receive email — no third-party email service needed.”
   • [claimed-docs] “get_logs — the first step for any 500, blank page, or failed request.”

   proof ↗⚑ flag

Export

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

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

   Floot✓fullclaimed8/10

   Floot's docs explicitly state you can export the code and database and deploy them wherever you like, directly matching the story of exporting source and self-hosting outside the platform. Missing for 10: independent/hands-on verification of the export process and details on completeness/portability of exported code beyond the doc claim.

   • [claimed-docs] “you can export the code and the database and deploy them wherever you like.”

   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

   Floot~partialclaimed5/10

   Floot lets you connect external editors (Cursor, VS Code, Zed) via its remote MCP server, giving access to tools like execute_sql, query_database and create_checkpoint that can modify the live project, and separately lets you export code/database for self-hosting — but there's no documented local file-sync or git-style push workflow; the platform's own framing emphasizes staying in the AI chat rather than local file editing pushed back. missing for 10: explicit local-editor file sync/push mechanism, evidence of two-way git-based workflow, independent confirmation this MCP path is used for real code editing rather than just DB/log operations.

   • [claimed-docs] “Add Floot to Cursor, VS Code, Zed, or any client that supports remote MCP servers”
   • [claimed-docs] “get_logs — the first step for any 500, blank page, or failed request.”
   • [claimed-docs] “query_database for reads, execute_sql for writes and migrations, pull_database_schema to regenerate typed helpers.”
   • [claimed-docs] “create_checkpoint labels a point you can revert to from the Checkpoint panel in your project view.”
   • [claimed-docs] “you can export the code and the database and deploy them wherever you like.”
   • [claimed-docs] “build and ship full-stack apps without leaving your AI chat”

   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

   Floot—none0/10

   The evidence pack shows Floot supports exporting code/database for self-hosting, but there is no mention of a GitHub integration or bidirectional repo sync anywhere in the docs, changelog, or probes.

   • [claimed-docs] “you can export the code and the database and deploy them wherever you like.”

   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

   Floot—none0/10

   No evidence in the pack mentions multi-user workspaces, team member invites, roles/permissions, or shared project collaboration features. Evidence focuses on AI chat tooling, MCP integration, mobile app conversion, self-hosting, and checkpoints, none of which speak to teams working together in a shared workspace.

   ⚑ flag

Domains

1. founderConnect a custom domain to my published app

   weight 2 · round to Lovable
   Lovable✓fullclaimed8/10

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

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

   proof ↗⚑ flag

   Floot—none0/10

   No evidence pack item mentions custom domain connection, DNS setup, or domain management for published apps; only deployment-adjacent features like self-hosting export and mobile app conversion are documented.

   ⚑ flag

Publish

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

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

   Floot~partialclaimed6/10

   Floot explicitly documents exporting code and database to self-host or deploy elsewhere, directly supporting this story, but details are thin—no evidence of specific export formats, supported hosts, CI/CD, or independent confirmation of a successful external deployment. missing for 10: detailed export/deploy workflow docs, supported infrastructure targets, independent hands-on verification of external hosting.

   • [claimed-docs] “you can export the code and the database and deploy them wherever you like.”

   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

   Floot~partialprobed6/10

   The llms.txt probe confirms Floot 'turns a plain-language description into a real, deployed full-stack app,' implying deployment is automatic as part of building, and self-hosting docs show apps can be exported/deployed elsewhere. However, there is no explicit documentation of a one-click 'publish' action, custom domain setup, or live URL management workflow. missing for 10: explicit publish/deploy button documentation, custom domain configuration details, confirmation of single-step publishing UX.

   • [probe] “PROBE llms.txt: HTTP 200 at https://floot.com/llms.txt # Floot > Floot turns a plain-language description into a real, deployed full-stack …”
   • [claimed-docs] “you can export the code and the database and deploy them wherever you like.”

   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

   Floot~partialprobed6/10

   Floot documents an official remote MCP server that can be added to Cursor, VS Code, Zed, or any MCP-capable client, letting an external agent drive builder actions like get_logs, query_database, create_checkpoint, and generate_image — this directly supports connecting an outside coding agent to the project. However, evidence doesn't confirm this fully replaces or runs 'alongside' the built-in agent in real workflows, nor is there independent/hands-on confirmation of external agents successfully driving full builds. missing for 10: hands-on/independent verification of external agent parity with built-in agent, clarity on simultaneous or exclusive control, and any limitations when using third-party clients.

   • [claimed-docs] “Add Floot to Cursor, VS Code, Zed, or any client that supports remote MCP servers”
   • [claimed-docs] “get_logs — the first step for any 500, blank page, or failed request.”
   • [claimed-docs] “query_database for reads, execute_sql for writes and migrations, pull_database_schema to regenerate typed helpers.”
   • [claimed-docs] “create_checkpoint labels a point you can revert to from the Checkpoint panel in your project view.”
   • [claimed-docs] “generate_image writes AI images into the project.”
   • [probe] “official MCP server documented at https://floot.com/docs/integrations/other-mcp-clients”

   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

   Floot—none0/10

   Floot's evidence describes chat/AI-driven building, MCP tool integrations, exporting code for self-hosting, and mobile/app features, but there is no mention of an in-builder code editor for directly viewing/editing generated source code within the product itself.

   ⚑ flag

Preview

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

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

   Floot~partialclaimed5/10

   Docs imply an interactive project view where users can 'point at an element or annotate a screenshot' for the AI, and a 'Checkpoint panel in your project view,' suggesting a live, before-publish preview exists — but no evidence explicitly describes a dedicated live-preview pane, its update speed, or founder-facing walkthrough of iterating on it before shipping. missing for 10: explicit live-preview UI documentation, screenshots/demo of pre-publish preview, independent hands-on confirmation.

   • [claimed-docs] “point at an element or annotate a screenshot for the assistant to pick up”
   • [claimed-docs] “create_checkpoint labels a point you can revert to from the Checkpoint panel in your project view.”
   • [claimed-docs] “build and ship full-stack apps without leaving your AI chat”

   proof ↗⚑ flag

Prompt iteration

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

   weight 3 · round drawn
   Lovable~partialcommunity5/10

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

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

   proof ↗⚑ flag

   Floot~partialclaimed5/10

   Floot supports checkpoint/revert (floot-docs-5) and chat-based iterative building (floot-docs-1), which are relevant to safely refining an app via follow-up prompts, but there's no direct evidence describing regression prevention, test coverage, or how the assistant avoids breaking existing functionality during edits. missing for 10: evidence of automated regression/testing safeguards, independent hands-on account of iterative prompting not breaking prior features, and detail on how conflicts between old and new instructions are resolved.

   • [claimed-docs] “build and ship full-stack apps without leaving your AI chat”
   • [claimed-docs] “create_checkpoint labels a point you can revert to from the Checkpoint panel in your project view.”

   proof ↗⚑ flag

Visual editing

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

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

   Floot—none0/10

   Floot's documented workflow is prompt/chat-driven — you 'point at an element or annotate a screenshot for the assistant to pick up' (floot-docs-6), which still requires an AI round-trip rather than direct in-canvas editing of text, style, or layout. No evidence describes a direct-manipulation editor mode for designers to bypass the AI prompt loop.

   • [claimed-docs] “point at an element or annotate a screenshot for the assistant to pick up”
   • [claimed-docs] “build and ship full-stack apps without leaving your AI chat”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   Lovable~partialprobed5/10

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

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

   proof ↗⚑ flag

   Floot~partialprobed5/10

   Floot exposes a documented MCP server with tools (get_logs, query_database/execute_sql, create_checkpoint, generate_image) that let an AI agent perform many core dev actions, mirroring parts of the UI workflow, but there's no public REST/OpenAPI API (probes return 404 for openapi.json/swagger.json and docs.md), so broader UI features like mobile app packaging, push notifications, email, analytics, and self-hosting export are not confirmed to be reachable via API. missing for 10: a general-purpose REST/OpenAPI API, evidence that all UI-exposed features (mobile builds, notifications, analytics, hosting/export) are also API-accessible, independent confirmation of API parity.

   • [claimed-docs] “Add Floot to Cursor, VS Code, Zed, or any client that supports remote MCP servers”
   • [claimed-docs] “get_logs — the first step for any 500, blank page, or failed request.”
   • [claimed-docs] “query_database for reads, execute_sql for writes and migrations, pull_database_schema to regenerate typed helpers.”
   • [claimed-docs] “create_checkpoint labels a point you can revert to from the Checkpoint panel in your project view.”
   • [claimed-docs] “generate_image writes AI images into the project.”
   • [probe] “PROBE docs-md: HTTP 404 at https://floot.com/docs.md”
   • [probe] “PROBE openapi: all candidate paths 404 (https://floot.com/openapi.json, https://floot.com/swagger.json, https://floot.com/api/openapi.json, …”
   • [probe] “official MCP server documented at https://floot.com/docs/integrations/other-mcp-clients”

   proof ↗⚑ flag

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

   weight 3 · round drawn
   Lovable~partialclaimed6/10

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

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

   proof ↗⚑ flag

   Floot~partialclaimed6/10

   Floot documents exporting both code and database for self-hosting elsewhere, directly supporting data portability and leaving the platform, but there's no evidence of a broader open-format export (e.g., structured data exports, account data, media assets) beyond code/DB, nor independent confirmation the export is complete or in fully open standard formats. missing for 10: evidence of full data export scope (assets, user data, configs), independent/hands-on verification of export completeness, and confirmation of open standard formats used.

   • [claimed-docs] “you can export the code and the database and deploy them wherever you like.”

   proof ↗⚑ flag

3. ai-native userSelf-host the core product

   weight 3 · round to Floot
   Lovable—none0/10

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

   • [claimed-docs] “Lovable hosts your app and includes a built-in backend (Cloud) with database, authentication, storage, edge functions, and AI, no infrastruc…”
   • [claimed-docs] “Lovable hosts your app and includes a built-in backend (Cloud) with a database, storage, authentication, realtime, and functions.”
   • [claimed-docs] “Build your first app and put it live on the web with about ten minutes of hands-on time. There is nothing to install and nothing to configur…”
   • [claimed-docs] “Anyone with an email address can sign up for free... Lovable automatically creates your first personal workspace on the free plan”
   • [claimed-docs] “centralized identity, granular access controls, workspace-wide security oversight, scheduled Deep scans, audit logs, regional code hosting”

   proof ↗⚑ flag

   Floot~partialclaimed5/10

   Floot is a hosted platform (not open-source), but docs confirm you can export project code and database and deploy them wherever you like, giving a path to self-host the exported app outside Floot's infrastructure. This is not self-hosting the core Floot platform/builder itself, just the generated output. Missing for 10: evidence of self-hosting the actual Floot builder/service, open-source availability, or independent confirmation the export-and-deploy path works end-to-end.

   • [claimed-docs] “you can export the code and the database and deploy them wherever you like.”

   proof ↗⚑ flag

Pricing

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

   weight 2 · round to Lovable
   Lovable~partialclaimed5/10

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

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

   proof ↗⚑ flag

   Floot—none0/10

   Only floot-docs-8 mentions a credit system (you can 'add credits whenever you need them'), but there is no documentation of what specific actions consume credits/tokens, how many, or what different plans include — the core of the founder's ask is unaddressed.

   • [claimed-docs] “you no longer have to upgrade or downgrade your plan — just add credits whenever you need them.”

   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

   Floot—none0/10

   No evidence anywhere in the pack mentions data residency, region selection, or hosting location choices; only self-hosting/export is mentioned which does not equate to choosing a storage region within Floot's platform.

   ⚑ 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

   Floot—none0/10

   No evidence pack item mentions AI training data usage, opt-out controls, or data-privacy commitments regarding model training; nothing addresses this axis at all.

   ⚑ 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

   Floot—none0/10

   No evidence pack items describe data retention controls, deletion policies, or privacy/export-of-personal-data mechanisms; export/self-hosting docs cover code/database portability, not retention or deletion settings. missing for 10: retention policy documentation, data deletion controls/API, privacy policy references, account/data purge mechanisms.

   ⚑ 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

   Floot—none0/10

   The evidence pack contains no mention of telemetry opt-out or privacy controls for AI-native usage; it only shows built-in visitor tracking for end-user apps (floot-docs-10), which is unrelated to Floot's own telemetry practices toward its users.

   ⚑ 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

   Floot—none0/10

   No evidence pack item mentions Figma import, design file import, or converting existing designs into a Floot app; the docs focus on chat-based prompting, MCP tools, mobile export, and self-hosting.

   ⚑ 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

   Floot✓fullprobed8/10

   Floot's own docs describe it as turning a plain-language description into a full-stack app with React+TypeScript frontend and backed by database tools (query_database, execute_sql, pull_database_schema), indicating both UI and backend logic are generated from a single prompt. This is corroborated by the llms.txt probe confirming the core positioning. Missing for 10: independent/hands-on developer confirmation of single-prompt generation quality and no explicit example walkthrough of a prompt producing both layers together.

   • [probe] “PROBE llms.txt: HTTP 200 at https://floot.com/llms.txt # Floot > Floot turns a plain-language description into a real, deployed full-stack …”
   • [claimed-docs] “query_database for reads, execute_sql for writes and migrations, pull_database_schema to regenerate typed helpers.”
   • [claimed-docs] “build and ship full-stack apps without leaving your AI chat”

   proof ↗⚑ flag

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

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

   Floot✓fullprobed8/10

   Floot's own docs describe turning plain-language descriptions into a deployed full-stack app (React+TypeScript frontend, database, backend tooling like query_database/execute_sql, image generation, mobile app conversion), directly matching the prompt-to-app story, and this is corroborated by a live probe of llms.txt confirming the same positioning. Missing for 10: independent/third-party hands-on reviews validating real-world output quality beyond vendor docs and probes.

   • [probe] “PROBE llms.txt: HTTP 200 at https://floot.com/llms.txt # Floot > Floot turns a plain-language description into a real, deployed full-stack …”
   • [claimed-docs] “query_database for reads, execute_sql for writes and migrations, pull_database_schema to regenerate typed helpers.”
   • [claimed-docs] “Floot converts your project into native iOS and Android apps”
   • [claimed-docs] “get_logs — the first step for any 500, blank page, or failed request.”

   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

   Floot~partialprobed6/10

   Floot exposes a remote MCP server with tools (get_logs, query_database, execute_sql, generate_image, create_checkpoint) that let an AI client programmatically manage an app's data, logs, and images, which is a form of programmatic control aligned with ai-native/prompt-to-app usage. However, probes show no REST/OpenAPI API (all openapi.json/docs.md paths 404), and there's no evidence of programmatically creating new apps from scratch via API—only managing an existing project through MCP tools. Missing for 10: a documented REST/OpenAPI platform API, evidence of app creation (not just management) via API/MCP, and independent confirmation of these tool calls working end-to-end.

   • [claimed-docs] “get_logs — the first step for any 500, blank page, or failed request.”
   • [claimed-docs] “query_database for reads, execute_sql for writes and migrations, pull_database_schema to regenerate typed helpers.”
   • [claimed-docs] “create_checkpoint labels a point you can revert to from the Checkpoint panel in your project view.”
   • [claimed-docs] “generate_image writes AI images into the project.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://floot.com/openapi.json, https://floot.com/swagger.json, https://floot.com/api/openapi.json, …”
   • [probe] “official MCP server documented at https://floot.com/docs/integrations/other-mcp-clients”

   proof ↗⚑ flag

Templates

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

   weight 2 · round to Lovable
   Lovable~partialclaimed5/10

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

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

   proof ↗⚑ flag

   Floot—none0/10

   No evidence in the pack mentions templates, starter kits, or community project galleries as a starting point for new Floot projects; all docs focus on chat-based generation, MCP integrations, and infrastructure features.

   ⚑ flag