Lovable, reviewed
The app builder behind the vibe coding boom is fast and fun. What it does well, why its apps often look alike, where security and lock in bite.
Lovable is the app builder that turned vibe coding into a business. You describe an app in a chat, and Lovable writes the code, sets up a database and sign in, and puts the result online. The Stockholm company launched in November 2024. In August it raised 400 million dollars at a valuation of 13.3 billion, and in September its cofounder Fabian Hedin said annualised revenue had passed 600 million dollars.
We build web and mobile apps for a living, so we look at Lovable from two sides: as a tool we enjoy using, and as the starting point for apps that later have to carry real customers and their data. Here is what it does well, where it falls short, and what it costs to stay.
What it does well
For a first version, Lovable is genuinely impressive. In our use, a sentence becomes a working app with screens, sign in, a database and a public link within an afternoon, without opening an editor. An idea can be tried on real people before anyone writes a specification, and that changes how early ideas get tested.
Many people want exactly that. Lovable says its users have created more than 60 million projects since launch, that apps built on it get more than 900 million visits a month, and that employees at nearly two thirds of the Fortune 500 use it. In a survey of its users, nearly eight in ten said they were building a business or side project they hope to earn from.
Lovable has also invested in safety. Since June, a basic scan checks the configuration, the database schema and its access rules every time an app is published, and administrators can block publishing while critical issues remain. Lovable is candid about the limit: the basic scan does not analyse the application code for logic flaws.
Everything looks alike
Our main reservation is taste, and this is our view from using it rather than a measurement. Apps built with Lovable tend to look the same: the same layouts, the same cards, the same soft gradients, a style that becomes recognisable after a few launches. For a prototype that does not matter. For a brand it does, because the first thing a customer notices is that nobody decided how the product should feel.
Good prompts, references and a design system can steer it. But the default pulls towards the average, and most people keep the default.
Who answers for security
The more serious question is security. In March 2025 Matt Palmer, then at the rival Replit, found that a site built with Lovable exposed its users' data, because the database rules that decide who may read which rows were missing or wrong. Scanning 1'645 projects from Lovable's own showcase, he and his fellow researchers found 303 vulnerable endpoints in 170 of them, exposing names, emails, payment details and developers' API keys. The flaw was registered as CVE-2025-48757, with a severity score of 9.3 out of 10. Lovable disputes it, on the grounds that each customer is responsible for protecting the data of their own app.
In April 2026 a researcher showed that any Lovable account could read the source code and AI chat history of other users' public projects. Lovable first wrote on X: “To be clear: We did not suffer a data breach.” Two days later it published a fuller account: a change in February had reopened access it had closed in 2025, reports to its bug bounty programme had been closed without escalation, and both its product and its first response had fallen short. The Register called the episode “a lesson in how not to respond to vulnerability reports”.
The pattern reaches beyond Lovable. In September the security firm UpGuard found about 16'000 databases on Supabase, the database service behind Lovable's apps, with tables anyone could read, many of them holding personal data, and TechCrunch linked the wave to apps built quickly with AI. Supabase says its projects are secure by default and that customers control their own configuration. Both can be true. In between often stands a founder who has never had to learn what a database rule is.
Lock in and cost
The code itself can leave. Lovable's documentation says the apps, code and content you create are yours, every plan can sync to a GitHub repository, and the frontend can be hosted anywhere. The backend is another matter. If an app runs on Lovable Cloud, the supported ways out are managed or self-hosted Supabase. Moving the database alone does not move sign in, file storage, realtime or edge functions, and for plain PostgreSQL or another provider Lovable says it does not support the move. The editor and its agent cannot be self-hosted at all.
Cost runs on credits. Pro starts at 25 dollars a month for 100 credits and Business at 50 dollars, and both scale up to 10'000 credits; 1'200 credits on Pro cost 294 dollars a month. While an app stays on Lovable, its hosting, its AI features and its connectors draw on the same credits as building does.
A first version is cheap. What is hard to predict, in our experience, is the cost of every change once an app has grown. Each prompt edits code that nobody on your side wrote or read, and with dozens of screens, roles and payment flows, a fix in one place can break another, and the repair is paid for in credits too.
Our verdict
Lovable is one of the quickest ways to put an idea in front of people, and it is a pleasure to use. Use it for prototypes, for pitches and for internal tools that hold no sensitive data. Before real customers and their data arrive, connect GitHub from the first day, have someone who knows security check every database rule, and decide whether the app should stay on Lovable Cloud.
That next step is what Werk is for. We build web and mobile apps with our clients on the platform we built for our own products, where accounts, roles and payments are made once and tested, people review every release, and the source code is yours. A Lovable prototype makes a good brief.
