Lovable

A hosted agent that builds a full web app from chat. The generated front end is React + Vite; Lovable's current template is TanStack Start, with a documented upgrade path from older React + Vite projects (https://docs.lovable.dev/features/upgrade-to-tanstack-start.md). The built-in backend, called Cloud, is built on Supabase's open-source foundation and gives you Postgres, auth, storage, edge functions and realtime without setting Supabase up yourself; you can also connect your own Supabase project instead (https://docs.lovable.dev/features/cloud.md). Cloud projects are hosted in Americas, Europe or Asia Pacific, chosen at project creation — and per the same doc, the region cannot be changed afterwards and projects cannot be moved between regions. Country-specific regions (Germany, Japan, United States East are the vendor's examples) are Enterprise-only, by request. Surfaces beyond the web editor include a desktop app, a mobile app, an MCP server, and a ChatGPT app, all documented at https://docs.lovable.dev/llms.txt.

Four things stand out, all checkable.

It does not charge per seat. Every plan, including Free, lists unlimited users and unlimited collaborators; you pay for credits, not headcount (https://lovable.dev/pricing). In a category where most AI dev tools charge $20–40 per developer per month, a five-person team on Pro at $25/month is a real structural difference, not a promotion.

Per-message cost transparency. The three-dot menu under any Lovable response shows what that specific response cost in credits, and Settings → Plans & credit usage breaks usage down by project and by person (https://docs.lovable.dev/introduction/credits-and-usage.md). Most credit-metered AI tools tell you the balance and nothing about where it went.

Credits roll over and top-ups last a year. Unused monthly plan credits roll over while the subscription stays active; monthly credits from a monthly plan expire two months from issue, and purchased top-up credits are valid 12 months from the most recent purchase (same doc). Paid plans also get 5 build credits per day on top of plan credits, with no monthly cap stated for Pro and Business — if you build most days, that is meaningful headroom the pricing page does not spell out.

A real exit. Lovable's own docs say projects can be continuously synced to GitHub or GitLab, cloned, modified outside Lovable and deployed on your own infrastructure or fully self-hosted (https://docs.lovable.dev/tips-tricks/deployment-hosting-ownership.md). See the portability section below for where that claim is tighter than it reads.

One balance now covers three different things: building your app, hosting it and running Cloud, and any AI calls your deployed app makes at runtime (https://docs.lovable.dev/introduction/credits-and-usage.md). Lovable notes this consolidation is still rolling out, so some workspaces may still see the older separate Cloud and AI dollar balances.

Included grants, per that doc: Free gets 5 build credits/day capped at 30/month, plus 20 Cloud credits and 4 AI credits per month. Pro and Business get 5 build credits/day plus the same 20 Cloud and 4 AI credits monthly, on top of their plan credits. Lovable flags the Cloud and AI grants as "a temporary offering and subject to change".

Build cost is not one credit per message. Plan mode is a flat 1 credit per message and never changes code. Build mode is usage-based — Lovable's own illustrative examples are 0.50 credits for "make the button gray", 0.90 for removing a footer, 1.20 for adding authentication and 2.00 for a landing page with generated images. Stopped requests are still charged for work completed. Lovable labels these as illustrative, not a rate card, so treat your own first month as the real measurement.

The part that matters operationally: if your balance reaches zero, building stops, AI features in deployed apps fail, and backend services — database, storage, authentication — "pause shortly after". Your published static pages stay live and your data stays safe, but per Lovable's docs you cannot access or export it until services run again. Auto top-up (Pro and Business only) exists specifically to prevent this, with a settable trigger threshold and monthly spend cap. Top-ups cost $15 per 50 credits on Pro ($0.30/credit) and $30 per 50 on Business ($0.60/credit) — roughly 20% above the equivalent plan rate on both tiers.

Pro and Business are ladders, not single prices (https://docs.lovable.dev/introduction/subscription-plans.md, verified 16 August 2026).

Pro: 100 credits $25 · 200 $50 · 400 $100 · 800 $200 · 1,200 $294 · 2,000 $480 · 3,000 $705 · 4,000 $920 · 5,000 $1,125 · 7,500 $1,688 · 10,000 $2,250 per month.

Business: 100 credits $50 · 200 $100 · 400 $200 · 800 $400 · 1,200 $588 · 2,000 $960 · 3,000 $1,410 · 4,000 $1,840 · 5,000 $2,250 · 7,500 $3,300 · 10,000 $4,300 per month.

Two things fall out of those tables. First, there is almost no volume discount: Pro is $0.25/credit at 100 and $0.225/credit at 10,000 — a 10% break for 100× the commitment. Business goes from $0.50 to $0.43, about 14%. Second, Business costs roughly twice Pro per credit at every rung, so the governance features (team workspace, SSO, role-based access, Security center, internal publish, priority support) are effectively priced as a 100% surcharge on all your consumption rather than a per-seat add-on. For a team that needs SSO but has modest usage that is fine; for a heavy-usage team it is the largest line in the bill.

Annual billing is about 17% off (100 Pro credits: $250/year against $300 paid monthly) and Lovable says it also raises rollover limits. Enterprise is a platform fee plus volume pricing, with no public numbers.

One downgrade trap worth knowing: if you drop to Free, unexpired monthly and rollover credits are frozen — unusable on Free and not refunded, though usable again if you upgrade before they expire (https://docs.lovable.dev/introduction/subscription-plans.md). Moving between paid tiers keeps them available.

Lovable deliberately does not let you choose the model. A "control plane" assigns parts of a build to different models based on how the build is going, and can re-route mid-build or fail over to another provider when one is overloaded. Lovable also says its own post-trained models now handle "a meaningful share of app-building work in production", starting with routing, summarisation and commit messages (https://lovable.dev/blog/the-model-picker-is-a-dead-end, published 11 August 2026).

The argument is coherent and the post is unusually candid about method — they describe recalibrating an LLM judge that ranked a hollow build highly, and dropping another that scored near-identical builds oppositely. If you want a tool that just works without you tracking the frontier, this is a feature.

The trade-off is equally real and worth stating plainly: you cannot pin a model, cannot reproduce a build against a known model version, and cannot tell from the outside which model wrote which part of your code. Because Build mode is priced by work done rather than per message, routing decisions also feed directly into what you are charged. If your procurement or compliance process requires you to name the models processing your code, that is a question for sales rather than something you can answer from the docs.

These are two separate issues and both matter.

The platform. On 20 April 2026 a researcher publicly showed that data inside public Lovable projects could be read by any authenticated user. Lovable's own post-mortem is the best source and is worth reading in full (https://lovable.dev/blog/our-response-to-the-april-2026-incident, 22 April 2026). Its account: chat history and source code on public projects had historically been visible by design; access was removed in stages through 2025 and all new projects became private-by-default in November 2025; a February 2026 backend regression re-enabled it. Between 3 February and 20 April 2026 public project chat history and source code could potentially be accessed by any Lovable user with a project link. Private projects and Cloud were, Lovable says, never affected. The fix shipped within two hours of public disclosure.

The process failure is the more instructive part, and Lovable states it directly: researchers filed valid reports through its HackerOne programme — the first on 22 February 2026 — and all were closed without escalation, because the triage documentation Lovable had supplied still described public chat visibility as intended behaviour. Lovable also writes that its "first public response was dismissive", that dates in its original communications were wrong, and that it is retraining triagers and converting historically public projects to private. Independent coverage is harsher on the sequence of public statements and dates the researcher's report to 3 March (https://thenextweb.com/news/lovable-vibe-coding-security-crisis-exposed); the two accounts differ on that date, and we have not established which is right.

The generated apps. In February 2026 researcher Taimur Khan found 16 vulnerabilities, 6 critical, in a single Lovable-built app that exposed 18,697 user records including student accounts at UC Berkeley and UC Davis, with authentication logic inverted so it "blocks the people it should allow" (https://www.theregister.com/2026/02/27/lovable_app_vulnerabilities/). These were flaws in a user's app, not in Lovable's platform, and Lovable's CISO Igor Andriushchenko said the platform provides free pre-publish security scans and flags issues but "it is at the discretion of the user to implement these recommendations". Broader context: Escape.tech scanned 5,600 publicly deployed vibe-coded apps — a sample heavily skewed toward Lovable, roughly 4,000+ of them — and reported 2,000+ vulnerabilities, 400+ exposed secrets and 175 PII exposures, though it publishes no per-platform breakdown (https://escape.tech/blog/methodology-how-we-discovered-vulnerabilities-apps-built-with-vibe-coding/, 29 October 2025). That is a category problem, not a Lovable-specific verdict, but Lovable is the largest single contributor to the category.

What Lovable ships against it. On-demand security scans are free on all plans; a workspace Security center (Business and Enterprise) aggregates findings, scan coverage, secrets names and dependency risk across every project, with CSV export, though it shows only the latest scan per project and no history (https://docs.lovable.dev/features/security-center.md). Enterprise adds scheduled deep scans (these consume credits), sensitive-data detection, and an Aikido agentic pentest integration. This is more security tooling than most peers ship. It is still tooling you have to run — the CISO's statement above is the operative one for who owns the outcome.

Time-sensitive: from 9 September 2026, customer data on Free and Pro plans — prompts, attached images and files, code, project files, generated outputs and usage data — may be used to train and improve Lovable's models unless you opt out. The opt-out is a free account-level toggle at Account settings → AI model training, has no feature cost, and can be set before or after the date; opting out before means your content is not used at all, opting out later excludes it only going forward and does not retract anything already in an assembled training set (https://docs.lovable.dev/features/business/data-opt-out.md). Business and Enterprise workspace data is excluded by default under the DPA. End-user data in your deployed apps and your billing details are excluded either way. Separately, from the same date Lovable may share limited pseudonymised identifiers with advertising platforms — consent-based in the EEA, UK, Switzerland and Brazil, opt-out in the US.

Compliance, per Lovable's enterprise docs and trust portal (https://docs.lovable.dev/introduction/lovable-for-enterprise.md, https://trust.lovable.dev): SOC 2 Type II, ISO 27001:2022, AIUC-1, GDPR with a DPA. Lovable states explicitly that it is not HIPAA-compliant and does not sign BAAs — do not put PHI in it. Enterprise adds SCIM, audit logs retained about 90 days with SIEM forwarding via the account team, GitHub Enterprise Cloud with data residency or GitHub Enterprise Server.

Lovable's docs open with "you are never locked in" and the Git sync story supports that — continuous sync to GitHub or GitLab, clone and deploy anywhere, self-host the whole stack (https://docs.lovable.dev/tips-tricks/deployment-hosting-ownership.md). For the front end and application code, that holds.

Two qualifications sit in the Cloud docs (https://docs.lovable.dev/features/cloud.md). There is no one-click migration from the built-in Cloud backend to your own Supabase project: you export your Cloud data, connect a Supabase project to a new Lovable project, and rebuild the schema there. Remixing does not switch backends. Migration in the other direction, from an existing Supabase integration into Cloud, is not supported at all. And the hosting region is fixed at project creation and cannot be changed. None of this is lock-in in the licensing sense — it is migration work, and you should size it before you build something load-bearing on Cloud rather than on your own Supabase.

Trustpilot is the only substantial pool of independent user reviews we could reach — G2, Gartner and Capterra block automated access. Lovable scores 4.1 out of 5, with the page listing 1,506 reviews and 1,027 in the last 12 months (https://www.trustpilot.com/review/lovable.dev, checked 16 August 2026). Read that against its direct peers on the same platform, same day: Base44 2.8 (835), Replit 2.9 (2K), Emergent 3.0 (593), Bolt 1.4 (198). Lovable is clearly the best-regarded of the prompt-to-app builders by this measure.

Two caveats keep it honest. Trustpilot's own transparency page shows Lovable actively solicits reviews, which lifts scores across the board — though its peers largely do the same. And the distribution is polarised rather than warm: 67% five-star, 17% one-star, over the last 12 months (https://www.trustpilot.com/review/lovable.dev/transparency). Trustpilot's AI summary of recent reviews names the recurring complaints as the AI struggling with complex tasks, generating recurring bugs and "consuming excessive credits during repeated troubleshooting attempts", plus unexpected billing issues — which lines up exactly with the usage-based Build mode pricing described above. Lovable replies to 20% of negative reviews.

We found no methodologically credible independent benchmark of output quality for this category. Treat any ranking you see as marketing until someone publishes a method.

Stockholm-based, launched November 2024 (rebranded from GPT Engineer). On 12 August 2026 Lovable announced a $400M Series C at a $13.3B valuation, led by Menlo Ventures and co-led by the EQT-managed Scaleup Europe Fund, with Tencent, Balderton, Kaszek, World Innovation Lab and Regent among new investors and Accel, CapitalG, DST Global, HubSpot Ventures and Salesforce Ventures returning (https://lovable.dev/blog/series-c; corroborated by https://techcrunch.com/2026/08/12/lovable-confirms-new-13-3b-valuation-raises-another-400m/). That roughly doubles the $6.6B valuation from its $330M December 2025 round. TechCrunch cites an annualised run rate of $500M as of June 2026. Vendor-stated usage: 60M+ projects created since launch and 900M+ monthly visits across Lovable-built apps; Lovable also says it plans to reach around 450 staff by year end.

For a buyer, the relevant read is simply that funding risk is not the concern here — this is a well-capitalised company scaling fast, and the trade-offs on this page are product and process trade-offs, not survival ones. The corollary is that a company growing this fast is changing its product constantly: the credit consolidation is described as still rolling out, and the Cloud and AI grants are explicitly marked as temporary.

Good fit: small teams and non-engineering functions building internal tools, prototypes and customer-facing apps where several people want to prompt and nobody wants per-seat licensing; anyone who values being able to lift the code into their own GitHub and keep going; teams that want SSO and a portfolio-level security view without an enterprise contract (Business, from $50/month).

Think harder if: you handle PHI (no HIPAA, no BAA); you must name and pin the models that touch your source code; you need a fixed, predictable monthly bill, since Build-mode consumption varies by prompt and the same balance drains from production hosting; or you are planning to run a business-critical service on Cloud, where an empty balance pauses backend services and migration off Cloud is a rebuild rather than a switch. For that last case, connect your own Supabase from the start.