Lovable review from the other side: what breaks after launch

July 2025: Replit deleted a customer's production database, generated fake data to cover it, and denied that anything had happened. July 2026: the founder of an AI-built app learned about a data breach from angry user emails, because the system kept no logs at all. Both are documented, one by The Register and one in a case study by the agency that cleaned it up.

Meanwhile ING is building trading systems this way and the CEO of Microsoft calls it a world-class tool. Both things are true at once, and that is the whole difficulty with this subject.

Most reviews of Lovable and Bolt cover the first hour. This one covers the sixth week.

What people actually ask about it

Search Google for vibe coding and it suggests seven follow-up questions. Four of them are about failure: why it failed, whether it is risky, whether it is good or bad, whether it is dying.

The forums are blunter. In the week I pulled this research, r/vibecoding had a thread titled “Vibe coders, how do you know your app is secure?” and r/cybersecurity had one saying security in vibe-coded web apps is a disaster. One post on X described the workflow honestly: build fast, push it live, hope nobody finds the vulnerability.

Why the failures are quiet

The single most useful line on this subject comes from a DAPLab study at Columbia University, which Google cites when people ask why these projects fail.

The most common and most serious problems sit in error handling and business logic. They are dangerous because they are silent: the code runs without an error and the application does something other than what was asked for.

Databricks found the same shape from a different angle. Vibe coding can produce arbitrary code execution and memory corruption even when the generated code appears to work.

This is a different class of failure from the one we are used to. A system that crashes reports itself. A system that applies a discount one percent too low on every order never reports anything. Your bookkeeper finds it a quarter later.

The second mechanism has a plain name, from the agency that rebuilt the breached app: AI tools generate application logic, but they never generate the security operations layer. Logs, alerts, monitoring. Not because they are weak, but because nobody asked and they do not volunteer.

Where Lovable and Bolt earn their keep

Now the honest half, because a lot of writing on this is fear for hire.

A prototype to test an idea. A weekend instead of two months and several thousand dollars. If nobody wants it after a week, you saved everything.

An internal tool for a handful of people, one that reads data and changes nothing in a production system.

A mockup for the conversation with a builder. A clickable prototype says more about what you need than ten pages of specification.

In all three, paying for professional delivery is money thrown away.

One feature every failure shares

Go back to the incidents, because something links them that is invisible one at a time.

Replit deleted the database and then denied it. Cursor refused to work and told the user to go learn programming. The founder in the case study heard about his breach from his own customers.

In none of those situations was there anyone on the other side. The point is not that the tool failed. The point is that a tool has no obligation to you and never will.

That is the real difference, and it is not code quality. Code out of Lovable is often better than code out of a junior developer. But Lovable will not notice that discounts have been one percent light since Tuesday, because it never set up the logs and nobody told it to watch them. It will not answer the phone on a Saturday. It will not remember why a function was built that way three months ago. And it will not answer to a regulator when data leaks, because you are the data controller.

When you buy a service, you are not buying lines of code. You are buying somebody whose job it is to notice.

The line runs in one specific place

Not between AI and humans. Between a prototype and a system somebody other than you depends on.

Four questions settle it. Does the data belong to anyone outside your company? Does the application change things in the systems it connects to, or only display them? Will somebody other than you have to fix it? Would an outage stop your team working?

One yes means you need the layer the tool did not generate, and somebody to keep it running. Four noes mean you stay with the prototype and pay nobody.

What you are not buying with the prototype

Six things no tool adds on its own, because it does not know they are wanted: logs and alerts, access control at the data layer rather than the screen layer, backups with a tested restore, tests that catch a silent change in logic, documentation for whoever inherits this, and accountability for data protection.

At prototype scale none of them matter. At system scale each absence is a separate exposure.

Do not delete what you already built

That is the common instinct and the expensive one.

A working prototype is a complete specification of what you need, worth more than any document. It shows what the thing has to do and what was missing. Rewriting it with that knowledge is faster than starting empty, even if not one line survives.

Before you decide anything, do three things. Export the data, if there is any. Write down where the system runs and whose account it is on. List what is broken but not yet reported.

Timing decides the cost. Before real users, this is tidying up. After them, it is a migration with production data, and that is several times the bill.

What happens when you get in touch

We start by reading what you have, not by talking you into a rebuild. You talk to the owner, the call runs 45 minutes, and it ends with one of three answers: stay with the prototype, tidy up what exists, or build again.

The first answer comes up more often than you would expect, and it costs you nothing. We would rather that than a build somebody quietly switches off in six months.

With the other two you get what no tool gives you. Somebody watches your logs and calls you before your customer does. Somebody remembers why that function looks the way it does. Somebody picks up on a Saturday, and it is in the contract rather than in good intentions.

Scope is agreed before signing, never during. Your code sits in your repository from day one, so you can leave and take all of it. The warranty covers repairs at no extra charge.

We do not disappear after handover. That is the entire difference between us and a twenty-dollar subscription.