I Built an App With Lovable. What Do I Need Before Launching?

I get a version of the same message every few weeks. Someone has built a working app in Lovable, it does what they want in testing, and they're now looking at a "publish" button wondering if that's actually it. It usually isn't. A prototype that behaves well when you're the only user is a different thing to an app with real customers, real money and real data behind it. Here's what I'd actually check before flipping the switch.

Who can see data that isn't theirs

This is the one I check first, every time. Lovable apps are usually built on Supabase, and Supabase's security model relies on something called Row Level Security (RLS). If RLS isn't switched on and configured properly for every table, any logged-in user can potentially query data belonging to other users, sometimes just by opening the browser's developer tools and calling the API directly.

It's an easy thing to miss because the app looks fine in the interface. Nobody's clicking a button that shows them someone else's invoices. But the API doesn't know that, it just returns whatever it's asked for unless you've told it not to. If your app stores anything a customer wouldn't want a stranger to see (emails, addresses, payment history, messages) this needs checking table by table before launch, not after someone reports it.

Where your secrets are living

API keys for Stripe, email providers, or any third-party service need to sit in environment variables on the server side, never in code that ships to the browser. It's a common mistake in fast-built apps because it works fine in testing and nobody notices the key is sitting in a public bundle until someone goes looking for it. Do a search through your codebase for any key that starts with things like sk_ and make sure it's not somewhere a browser can read it.

What happens if the database gets wiped

Ask directly: does your database provider run automatic backups, and have you actually tested restoring one? Plenty of people discover the answer is no at the worst possible moment. Even a basic daily backup that you've confirmed you can restore from is worth more than a fancier feature nobody's tested.

Payments and webhooks

If money moves through the app, check three things specifically:

• Webhooks are verified with a signing secret, not just trusted because they arrived at the right URL.
• Failed or disputed payments are handled somewhere visible, not silently ignored.
• You're not relying on the browser to confirm a payment succeeded. Confirmation should come from the payment provider's server, not from whatever the user's browser reports back.

I've seen bookings marked as paid because the customer's tab was closed at the wrong moment, with the actual card charge never completed. That's the kind of bug that only shows up once you've got real customers, which is exactly why it needs testing before then.

What you're legally required to have

A privacy policy and terms of service aren't optional extras once you're collecting any personal data or taking payment in the UK. You need to say what data you collect, why, how long you keep it, and who it's shared with (this matters if you're using AI features, since it usually means data is sent to a third-party model provider). If you're VAT registered or a limited company, your invoices and terms need the right details on them too. None of this is complicated to add, but it's easy to forget when you've been focused on getting the features working.

What happens when traffic doesn't look like your testing

Lovable apps are usually fine for the load one person generates while building. They're untested for what happens when fifty people sign up in a day, or someone uploads a much larger file than you expected, or three people edit the same record at once. You don't need to solve every edge case before launch, but it's worth knowing which ones you haven't checked, rather than finding out live.

Who actually understands the code

If Lovable generated most of the app, ask yourself honestly whether you (or anyone) could explain what a given piece of it does and why. This matters the day something breaks or a customer asks for a feature that touches billing or data export. AI-assisted builds are genuinely good for getting to a working version fast, but "it works" and "someone understands it" aren't the same claim, and only the second one holds up once you're depending on it commercially.

The practical route from here

None of this means starting again. Most of what I've listed is a focused pass through an existing app: locking down data access, moving secrets server-side, setting up real backups, checking payment flows properly, and adding the legal basics. I do exactly this kind of work, taking a Lovable, Bolt or Replit build and hardening it into something you can safely put paying customers behind, without throwing away what already works. If you want a second, experienced pair of eyes on what you've built before launch, that's a conversation worth having before the app goes live, not after something's gone wrong.