You built it in Lovable. Now what?

You had an idea you'd been carrying around for a couple of years. The quoting process that lives in six spreadsheets. The job board your team runs off a group chat. The booking system you've been paying $180 a month for and hate.

Then you tried Lovable (or Replit, or Bolt, or Base44, or v0, they all work much the same way), and over a weekend the thing existed. It had a login page. It looked good. You showed someone and they asked if they could use it.

Maybe you stopped there. Plenty of people don't. Maybe your team has been using it for months, maybe a whole department runs on it now, maybe it's quietly become the most useful piece of software your business owns.

Worth stopping on that for a second, because it deserves more credit than it usually gets. Taking the way you work, the process that's been in your head for fifteen years, and turning it into working software yourself, with no development team and no budget, is genuinely new. There has never been anything quite like it. The person who understands how the business actually runs is now the person who can build the system, and that changes things. It might be the best thing AI has done for small business so far.

But there's a gap between an app that works and an app you can run a business on. You can be running your business on it today and still be sitting in that gap, because it doesn't announce itself on day one. It turns up later.

Building a whole working app this way, as an ordinary business person rather than a developer, has only really been viable for about the last eight to ten months. Most of these apps haven't hit anything yet. The problems arrive after the first twelve months. After the business grows. When you want reporting out of it. When it needs to talk to your accounting system. Or on the morning someone gets in, and you're the one explaining to your customers how their personal details ended up public.

The app works. That was never the question. You made it work and it works well.

The question is whether it's safe, whether it's built in a way that holds up, whether it'll still be serving you in three years, and, probably the most important one, whether it's capturing the right information. Because the day you want to know which jobs made money, or where the hours actually went, you can only answer with what the system bothered to record.

That's the gap. That's what this is about.

What you actually built

You need to know this bit, because everything else follows from it.

A Lovable app is three separate things that happen to be sold together. There's your code, which is a standard React and TypeScript project built with Vite. There's the frontend, the part that runs in your customer's browser. And there's the backend, which is a Postgres database plus login handling and file storage, packaged as Lovable Cloud.

None of it is proprietary. That matters later. It's ordinary open source technology that would run anywhere, and Lovable is quite clear about that. Their words: "we want you to stay with Lovable by choice, never by necessity."

The important part is how those three pieces talk to each other. In a traditional app, the browser asks a server for something, the server checks whether you're allowed to have it, and only then does the server go to the database. Three steps, and the middle one is where the security lives.

Lovable apps skip the middle step. Your customer's browser talks to the database directly, using a key that's published in your app's JavaScript. Anyone can read that key in about ten seconds. That's fine, that's the design, and it's why these apps are so quick to build.

But it means the only thing standing between the open internet and your customer table is a set of database rules called Row Level Security. Not a server. Not a login screen. Those rules.

Hold that thought.

Five things that will bite you

1. Your database is exposed, and one setting is the lock

Because the browser talks straight to the database, anybody can take that public key out of your app and start asking the database questions directly. Not through your app. Around it. Your login screen isn't in the way, because your login screen is just a page.

Row Level Security is what decides whether those questions get answered. It's meant to say things like "you can only read the rows where the customer ID matches you." When it's set up right, an attacker with your key gets nothing.

When it isn't, they get everything.

In May 2025 this got a formal vulnerability number, CVE-2025-48757, rated 8.26 out of 10. The researcher who found it sampled 1,645 Lovable apps and found 170 leaking personal information to anyone who asked. Around 70% had Row Level Security switched off entirely. What came out wasn't just names and emails. It was other people's API keys stored in database rows, and in some cases attackers could write as well as read, including changing whether an order had been paid for.

There's a subtler version that catches people who've done everything else right. These rules work on whole rows, not on individual columns. If one row holds a customer's name and their payment reference, a rule that lets someone see the name hands over the payment reference too. You can't fix that with a better rule. You have to split the table.

2. Secrets in the browser aren't secrets

If your app talks to Stripe, or an email service, or a mapping API, it needs a key for that service. Those keys are worth money to whoever finds them.

Anything in your app's frontend code is public. Not hidden, not obscure, public. Anyone can open your site, hit F12, and read it. This catches people constantly, because it isn't obvious if you haven't built for the web before. Variables starting with VITE_ feel like settings tucked away somewhere private. They're baked into the JavaScript when the app is built and shipped to every single visitor.

When the security firm Escape scanned 5,600 vibe-coded apps in late 2025, they found over 2,000 serious vulnerabilities, 400 exposed secrets and 175 cases of personal information sitting in the open, including medical records and bank details. They noted two things worth repeating. Most of it needed no login at all to reach. And they deliberately scanned gently, so the real numbers are higher.

Some of what they found were admin-level database keys. Those bypass Row Level Security completely. One of those in your frontend and none of the rules in point one apply to anyone who has it.

3. Your backups are worse than you think

Lovable Cloud takes one snapshot of your database a day and keeps about fourteen of them. On paper that sounds fine.

Work through what it actually means. The snapshot runs overnight. Something goes wrong at 4pm. Your most recent good copy is from sixteen hours ago, so you've lost a full day of orders, bookings, messages and job notes. Not corrupted. Gone.

Then there's the restore itself. Rolling back to a snapshot reverts your database structure as well as your data, so if you've changed anything since, your app comes back up not matching its own database. Lovable's documentation is upfront about this and suggests asking the AI to patch the mismatch afterwards. That's a second outage, during your first one.

And the backups only cover the database. Every file your customers have uploaded, every photo, every signed PDF, sits in separate storage that isn't in the backup at all.

None of this is unusual for a platform at this price. It's just very different from what most people assume "we take backups" means, and it's the single most common thing I see people get wrong about their own systems. I'll come back to this one on its own, because the ideas behind it are worth knowing properly whatever you've built on.

4. The platform is a supplier, and suppliers have bad weeks

On 20 April 2026, a researcher opened a free Lovable account and read another user's source code, database credentials and AI chat history. It took five API calls. No hacking, no exploit, just asking for something they shouldn't have been given.

They'd reported it through Lovable's bug bounty programme on 3 March. It was closed without being escalated. By the time it went public it had been open for 48 days. The Register covered the whole thing, including getting a statement out of the bug bounty provider.

Lovable's first response was to say there'd been no breach and the behaviour was intentional. Then they blamed their own documentation. Then they blamed their bug bounty partner. Then, later the same day, they apologised for the apology. Their proper post-mortem two days later is worth reading, because it's honest in a way the first day wasn't. Anton Osika: "the team learned about the incident on X because our own vulnerability disclosure process was broken."

The root cause is the interesting part for you. Lovable projects have two separate visibility settings. One controls who can see your published website. The other controls who can see your project inside the editor, meaning your source code and your entire build conversation. Lots of people read "public" as the first one. On the free tier it meant the second one too, and it was the default until late 2025. A backend change in February 2026 accidentally switched old protections back off.

Nobody did anything wrong. They just didn't know what the setting meant.

5. It gets less secure the longer you keep prompting

This is the one almost nobody knows, and it changes how you think about all of the above.

Three researchers ran a controlled experiment: 400 code samples, 40 rounds of "improvements" each, four different prompting styles, with a security scan after every single round. After just five rounds, the code held 37.6% more critical vulnerabilities than the first version. Your app is at its safest on the day it's born.

The detail that should worry you most is what happened when they asked nicely. Prompts that explicitly emphasised secure coding still introduced 38 new vulnerabilities, seven of them critical, and produced the highest error rate of any strategy in cryptography. Kaspersky's write-up is the readable version if you'd rather not read the paper.

It makes sense once you see it. The model does the thing you asked for. It doesn't remember the constraint it carefully satisfied four prompts ago, and it can't see the whole picture as the app grows. Every fix is a local fix. This is also why the standard community advice when Lovable starts behaving oddly is "start a fresh chat", which works, and also means throwing away everything it knew about your app.

And it doesn't quietly get cleaned up later. A team at Singapore Management University tracked 302,600 AI-written commits across 6,299 real GitHub projects and pinned 484,366 problems on them. More than a fifth were still sitting in the code at the latest version of the project. Nobody ever went back.

So one security check before launch doesn't cover you. The job is re-checking after every significant round of changes.

What to do this week

None of this costs money and none of it requires a developer.

Connect it to GitHub. Twenty minutes, free, built into Lovable, and it's the single most valuable thing on this list. Your code syncs to a repository you own. It doesn't change anything about how you work, and it converts "we're stuck with this platform" into "we're staying because we want to." Do it before you decide anything else.

Check your project visibility. Not your published site. The project itself, in the editor. This is exactly what the April incident was about.

Run the security scans. Lovable has two built in. The basic one runs automatically before you publish. The deep one, which is the useful one, doesn't run unless you ask it to. Both are free and neither costs credits. Run the deep scan today and fix anything marked critical.

Try to break in. Open your app, press F12, go to the network tab, and find the requests going to your database. Take that address and key, and try to read a table you shouldn't be able to see. If you get data back, you've just found what an attacker would find, and you found it first.

Work out what you'd lose. Pick a time of day, assume everything since last night's backup is gone, and write down what that costs you. If the answer is "a few test records", relax. If it's a day of customer orders, you need your own backup, not the platform's.

Then take a proper look at where you've landed. Lots of these apps should stay exactly where they are, hardened, on Lovable, forever. An internal tool with six users and no customer data has no business being migrated anywhere. But if you're now holding other people's personal information, taking payments, or the app has quietly become the thing your business runs on, you've crossed a line that the original weekend build was never meant to cross.

That's not a reason to start again. Most of what's needed is a few days of unglamorous work by someone who knows where to look.