Key findings
- 48 of the 52 accounts that discuss speed reached a first working app quickly.
- Fix-and-break loops are the concern raised most, by 22 of the 28 accounts that discuss them. Credit spend comes up in 33 accounts, and 17 raise it as a problem.
- 10 accounts run Lovable-built apps in production and 7 keep them to prototypes. Teams and leaders lean toward prototypes, 5 to 3.
- Outside researchers who scanned published Lovable apps found missing or permissive row-level security in 7.1% to about 10% of them, depending on which apps they scanned.
- 13 accounts say an app needs human review of access rules and logic before real users or company data touch it.
Use Lovable for prototypes and small internal tools, and budget an engineer's review before real users or company data arrive. Across 110 public accounts from January 2025 to October 2026, product managers, founders, designers, engineers, and teams praise how fast Lovable reaches a first working app. Their most common complaint is fixes that break other parts of the app.
Who builds, and what
Two uses dominate the team accounts. Product people build prototypes to replace documents. OneTeam's CTO, Guido Schmitz, screenshots the product into Lovable to test a change with customers. He reports that each iteration fell from four or five days to under a day. Product leaders interviewed by Teresa Torres describe customer tests built in about an hour. Others build internal tools. Kanbanchi runs its time, pay, and leave system on a Lovable app. A client of madewithlove gave students a Lovable workflow for processing geological datasets, and a project manager built a scoping tool for the team in an afternoon.
Lovable's own customer stories are vendor material. In them, a Delivery Hero product lead uses prototypes to get colleagues to agree on a direction, and Nursa encourages its 200 employees to build tools for their own teams.
Where it saves time
The first version arrives fast. Paweł Huryn, a former CPO who does not write React, launched a SaaS built in about 16 hours and 340 credits. Builders credit the Supabase-based backend, which wired sign-in and data for them, and Git sync, which let engineers or coding agents continue the code.
The time saved is clearest where the alternative was a queue. Examples are a tool no engineer would prioritize, or a prototype that would otherwise be a requirements document and a round of meetings.
Where it stalls
As apps grow, fixes start breaking other parts. One builder's one-click move of an older app to TanStack server rendering broke navigation and sign-up and cost three days and more than 100 credits. In a recorded build, nearly 60% of Peter Ramsey's messages were pointing out bugs, and another builder counted 482 messages on a shipped app, most of them corrections. Anton Zaides's hackathon team finished 90% of its project on the first day, then watched small changes break the app until it slowed down to plan each area.
Because each fix draws credits, loops cost money as well as time. A founder who came to Chaitanya Shetty's studio had spent over US$2,000 on credits and still had no usable prototype. Once real users arrive, Lovable Cloud usage adds a running cost, and one builder could not trace which part of the app drove it.
Security and data
Outside researchers scanned published Lovable apps. Matt Palmer, who reported CVE-2025-48757, found inadequate row-level security on 303 endpoints across 170 of 1,645 apps. Escape scanned more than 5,600 vibe-coded apps, mostly Lovable, and reported over 2,000 vulnerabilities and 400 exposed secrets. Securityscanner.dev found critical issues in 34 of 476 Lovable apps. Each affected app had a table with row-level security disabled. In one EdTech app from Lovable's public app gallery, Taimur Khan found 16 vulnerabilities, 6 of them critical, that exposed 18,697 user records without sign-in.
Separately, Lovable says a regression between February 3 and April 20, 2026 exposed public projects' chat history and code to any Lovable user with a link. It says it fixed the issue within two hours of the public report. Lovable's quick scan now checks row-level security on every publish, and its docs say no scan replaces a security review.
What the teams that kept it changed
The teams that kept Lovable added structure around it. madewithlove put a rules file in the repository and made CI block changes to infrastructure. Kanbanchi kept pay, customer data, and security in a supervised zone with developer review. Anoop Vijayan runs separate dev and prod projects and promotes changes by pull request. Knak, a team with a mature design system, went the other way and moved designer prototyping into its codebase.
- Store rules in Lovable workspace knowledge or a repository rules file.
- Have an engineer review row-level security and connectors before an app is shared.
- Separate experiments from the app colleagues depend on.
- Decide in advance which problems go to engineering.
Methodology
GILD read 110 public accounts from Lovable builders and teams, published from January 2025 to October 2026 and opened on October 12 or October 25, 2026. They include Hacker News and r/lovable posts read through Arctic Shift, blogs, dev.to posts, security research, X posts, and recorded talks, podcasts, and videos. Counts tally those accounts and do not estimate all Lovable users. Figures from Lovable's customer stories are the vendor's own. GILD checked product behavior against Lovable's documentation on the same dates.
Products in this piece
Sources
- Public source
- 17
- Official documentation
- 6
- Love At First Try podcast: Guido Schmitz, CTO of OneTeam (Jun 4, 2026)
- Product Talk: AI prototyping with Lovable, interviews with product teams (Aug 13, 2025)
- Kanbanchi blog: Building Internal Tools With AI, a bootstrapped team's honest account (Aug 1, 2026)
- madewithlove: "I built it in Lovable", an engineer's survival guide (May 14, 2026)
- Jamie Wright: AI made me a developer again. Kind of. (Jul 20, 2026)
- Paweł Huryn, The Product Compass: launching a SaaS built in Lovable (Aug 11, 2025)
- EffortfulCool in r/lovable: moving an older project to TanStack (Oct 3, 2026)
- Peter Ramsey, Built for Mars: Lovable case study (Oct 14, 2025)
- prompts2products: Don't use Lovable (Aug 16, 2026)
- Anton Zaides, Manager.dev: Cursing the day Lovable was born (Jul 14, 2026)
- Matt Palmer: Statement on CVE-2025-48757 (May 29, 2025)
- Escape: How we discovered vulnerabilities in apps built with vibe coding (Oct 29, 2025)
- securityscanner.dev: Lovable vs Bolt vs Replit, who is leaking the most Supabase data (Apr 16, 2026)
- Taimur Khan on LinkedIn: Lovable? More Like Hackable (Feb 26, 2026)
- Chaitanya Shetty on X: Lovable, Bolt and v0 are a disaster for MVPs (Oct 24, 2026)
- Anoop Vijayan: From Prototype to Production With Lovable.app (Aug 18, 2026)
- Knak: How Knak's designers prototype directly in the codebase (May 7, 2026)
- Lovable blog: How Delivery Hero green-lights features 66% faster (Nov 18, 2025)
- Lovable blog: How Nursa built a new product in 48 hours (Jul 1, 2026)
- Lovable blog: Our response to the April 2026 incident (Apr 22, 2026)
- Lovable docs: Security overview
- Lovable docs: Connect to Supabase
- Lovable docs: Sync with GitHub, GitLab, or Bitbucket