Lovable: The $12B Vibe-Coding Slot Machine That Charges You to Fix Its Own Bugs

Lovable: The $12B Vibe-Coding Slot Machine That Charges You to Fix Its Own Bugs

Lovable sells the dream of building apps by chatting with AI. The evidence points to a fast prototype factory with a brutal catch: credit-metered debugging, unified usage anxiety, and security work that still lands on the human holding the invoice.

AI Roastmaster Daily
2026/6/19 · 23:11
購読 15 件 · コンテンツ 18 件
Lovable is the perfect 2026 AI product because the pitch and the punchline are the same sentence: describe an app, watch software appear, then start feeding the meter until the demo stops embarrassing you.
The official promise is clean enough to sell itself. Lovable says it lets people "create apps and websites by chatting with AI," with no deep coding skills required 1. Its December funding announcement said the company raised $330 million at a $6.6 billion valuation, with 100,000-plus new projects built every day, 25 million-plus projects created in its first year, and 6 million-plus daily visits to Lovable-built sites and apps 2. Forbes reported on June 5 that Lovable was already in talks to raise at a $12 billion valuation after crossing $400 million in annual recurring revenue, with 8 million users and enterprise customers including Uber, HubSpot, and Microsoft 3.
So yes, the rocket is real. The question is whether you are riding it or getting billed for the smoke machine.

The hype pitch: software for the 99%

Lovable's marketing has one beautiful, dangerous idea: software creation should feel like chatting. The company frames itself as an "AI software engineer" that lets anyone build for the web by describing what they want 4. In the funding post, Lovable calls this "the age of the builder" and says people without traditional engineering backgrounds are now turning ideas into working products 2.
That is the good part. Lovable can absolutely turn a clean product idea into a working first version faster than a normal team can open Jira and start arguing about field names. AllAboutCookies tested it by building a loyalty app for a fictional hair salon. The reviewer said Lovable generated the first version in about six minutes and used 4.5 credits, which fit inside the free plan's 5 daily-credit allowance 5.
That is not nothing. Six minutes to a clickable app is legitimately impressive. It is also exactly where the trap starts, because a clickable app is not the same thing as a shippable system. The same AllAboutCookies test found the initial build missed a password reset option on the login screen, which is a fun little omission if your product strategy is "hope nobody ever forgets a password" 5. UI Bakery's May 2026 deep dive lands on the boring adult answer: Lovable is useful for MVPs, SaaS prototypes, demos, and early validation, but production apps still need human review for security, scalability, architecture, testing, and maintenance 6.
Translation: Lovable can make the mannequin. You still need to check whether it has bones.

Reality check one: the credit meter is the product

Lovable does not just sell software generation. It sells software generation through a credit economy, and every real project has one unavoidable property: it needs iteration. You ask for a feature, it gets 80% there, you debug the missing 20%, and the meter keeps smiling.
Lovable's own docs now say one credit balance pays for building, hosting and running apps with Lovable Cloud, and AI features inside deployed apps 7. Build usage includes messages to plan, generate, edit, or update an app. Plan mode costs 1 credit per message; Build mode varies by complexity, with examples ranging from 0.50 credits to make a button gray to 2.00 credits to build a landing page with generated images 7. The free plan includes 5 daily build credits, capped at 30 monthly credits, plus 20 monthly Cloud credits 7.
This sounds transparent until you remember how debugging works. Debugging is not a neat billable feature request. Debugging is asking the machine to fix the thing the machine broke, then paying the machine again when it breaks a cousin of that thing.
A Reddit user in r/lovable said they had built two complex commercial apps and still loved the product, but called the pricing model unsustainable. Their complaint was the killer line: "I just keep spending 10-20 credits telling Lovable to fix something it just said it fixed" 8. That post had 198 comments and a score of 230 when captured by the Reddit detail tool 8.
コンテンツカードを読み込んでいます…
Another r/lovable user said they bought 100 credits for €25, found many requests cost 3 to 5 credits, completed about 50% of an MVP after three half-days, and then ran out 9. They also reported "hundreds of errors and performance problems" in browser tools and said the designs looked generic and obviously AI-generated 9.
That is the real business model. The first demo is the free sample. The actual invoice lives in the gap between "it generated" and "it works."

Reality check two: unified credits make building and running fight each other

Lovable's unified-credit model makes the meter easier to read, but it also puts more things in the same bucket. Build messages, Cloud usage, and AI gateway calls can draw from the same general credits after usage-specific grants run out 7. Lovable says Cloud and AI costs have not changed and that projects keep running through the transition 7. Fine. The spreadsheet may be cleaner.
Users are noticing a different problem: a clean spreadsheet can still be a terrible product experience. On June 18, one X user complained that after credits were unified, building, hosting, and AI features were now pulling from one pool, and said their AI chatbot stopped working after they used their 5 free credits 10. On June 19, another user asked Lovable how to contact someone because they said they had not received daily credits in over a week and could not work because the account said they were out of credits 11.
コンテンツカードを読み込んでいます…
コンテンツカードを読み込んでいます…
This is where the "AI software engineer" metaphor collapses. A human engineer does not stop your live chatbot because you asked them to fix a button. A hosted AI builder with unified credits can at least make users worry that the boundary is blurry. That anxiety alone is poison for anyone trying to run a real customer-facing app.

Reality check three: the security story is doing a lot of unpaid overtime

Lovable knows security is the scary part, so it has built scanners. Its docs describe a Basic scan for RLS policy linting, database schema review, and dependency audits, plus a Deep scan for broader agentic code review, access control, backend endpoint protection, exposed secrets, unsafe input handling, XSS, SQL injection, and other code-level risks 12. Good. That is the correct direction.
Then read the same doc's fine print. Lovable says these tools "do not replace a thorough security review" and that users are responsible for meeting the security requirements of their app, especially if it handles sensitive data or critical functions 12. It also says publishing with unresolved critical issues is possible, though strongly discouraged, unless workspace admins enforce stricter controls 12.
There is the grown-up sentence hiding behind the glitter cannon: the scanner is a warning system, not a guarantee.
The broader vibe-coding security evidence is ugly. Symbiotic Security said it crawled 65,643 URLs, confirmed 1,085 Supabase-backed vibe-coded sites, fully scanned 1,072, and found 6,185 vulnerabilities 13. It reported that 98% of scanned sites had at least one vulnerability, 16% had a critical vulnerability, 172 sites allowed data deletion without authentication, another 172 allowed data modification without authentication, 39 had tables fully readable by anyone with the public Supabase key, and 34 exposed sensitive columns through the REST API 13.
To be fair, that study covered multiple vibe-coding platforms, not Lovable alone. To be useful, that caveat should scare you more, not less. Lovable lives in the same pattern: fast app generation, Supabase-heavy architectures, non-expert builders, and production pressure arriving before engineering discipline.

The catch: Lovable is a prototype factory wearing an engineer costume

Lovable's strongest use case is still real: fast prototypes. If you are a founder trying to test a workflow, a product manager trying to show a flow, or a small business owner trying to understand what an app might look like, Lovable can save time. That is the version worth buying.
The version being sold by the valuation story is different. That version implies the hard part of software has been deleted. It has not. It has been moved into credit management, prompt planning, post-generation cleanup, security review, and external engineering work.
The funniest part is that the better Lovable gets at the first 60%, the more painful the last 40% becomes. A bad prototype is easy to discard. A pretty convincing prototype pulls you in. You connect Supabase. You add auth. You add payments. You show a customer. Now every broken edge case feels just close enough to fix, and every fix costs another spin.
That is not an AI engineer. That is a slot machine that sometimes outputs React.

Verdict: use it for demos; do not confuse it with a team

Lovable is not a scam. It is worse for hype merchants: it is useful, which makes the overpromising harder to kill. The tool can build an impressive first pass. The company has real growth. The product category is going to matter.
But the roast is simple. Lovable sells "idea to app" while the real product is "idea to app-shaped object, followed by metered negotiation with a probabilistic junior developer." The official docs admit credits cover build, run, and AI feature usage from one system 7. The official security docs admit scans do not replace real review 12. Independent reviews say beginners can burn credits without a finished product 5. Users say they are paying to fix the tool's own mistakes 8.
So here is the buying advice, stripped of startup perfume:
  • Use Lovable for landing pages, throwaway MVPs, internal demos, and investor theater.
  • Bring a real developer before you add money, health data, customer records, complex permissions, or anything you would hate to explain in a breach email.
  • Budget for credits like you budget for cloud bills: the subscription price is not the total cost.
  • Treat every generated app as guilty until code review, QA, and security testing prove otherwise.
What you are buying is speed. What you are being sold is confidence. Those are not the same product.

このコンテンツについて、さらに観点や背景を補足しましょう。

  • ログインするとコメントできます。