Launching your Lovable app for real: 8 things every vibecoded webapp is missing (a founder's checklist)

You built a working webapp in Lovable over a weekend. The demo looks great. Your first beta users have already poked around it. You're about to point your real domain at it and start sending paying customers.

Stop for a second.

The webapp that Lovable (or Bolt, or v0, or Cursor) just gave you is, almost certainly, not yet safe to put in front of paying customers. Not because Lovable did anything wrong — it did the hard part beautifully — but because there's a whole layer of "boring stuff" that AI tools don't yet handle for you. The boring stuff is the difference between a working demo and a real product that won't blow up in your face.

We've quietly audited about a dozen vibecoded apps in the last six months, mostly for founders just like you. The same eight gaps show up every single time. Some of them you can close in an afternoon by yourself. Some need an hour of a developer's time. None of them require you to throw away what you've built.

This post is the checklist we wish every non-technical founder ran before going live.

Why "vibecoded" doesn't mean "ready"

Here's what's going on. AI coding tools are really good at the visible parts of a webapp: the pages, the buttons, the forms, the database calls, the login screen. That's the bit that shows up in the preview window, and that's the bit the AI has been trained on the most.

What they're not yet good at is everything you can't see in the preview: keeping your API keys secret, making sure strangers can't read your customer list, stopping someone from running up a $30,000 OpenAI bill overnight, telling you when something's broken, and making sure tomorrow's update doesn't accidentally break yesterday's signup flow.

You don't need to become a developer to handle this. You need a checklist. Here it is.

The 8 gaps every vibecoded app ships with

1. Your secret keys are probably visible to anyone

Most webapps need a handful of secret keys — like passwords that let your app talk to other services (OpenAI for AI features, Stripe for payments, Supabase for the database, Resend for emails). These keys are valuable. If someone gets one, they can run up bills on your account, or read your customers' data.

The problem: when Lovable wires up your app, it sometimes accidentally puts these keys in the part of the code that gets sent to your visitor's browser. That means a curious person with five minutes can copy your keys straight out of your app, like reading a sticker off the side of your laptop.

The business risk: Someone uses your OpenAI key to run their own AI project and you pay the bill. Someone uses your Supabase key to copy your customer list. Someone uses your Stripe key to issue refunds to themselves.

What to do (15 minutes, no developer needed):

• Open your live app in Chrome. Right-click → "Inspect" → click the "Sources" tab.
• Press Cmd+F (Mac) or Ctrl+F (Windows). Search for sk_. Then search for service_role. Then search for api.openai.com.
• If anything shows up, write down which keys are visible. Don't panic — but do treat those keys as already stolen, even if nothing has happened yet.

Then: Log into the provider (OpenAI, Stripe, Supabase, whoever owns that key) and rotate it — that means generate a new one and delete the old one. This takes about two minutes per key. Then ask a developer (or your Lovable AI assistant) to move that key to the "server side" so it doesn't end up in the browser again. The phrase to use is: "Make sure my OpenAI key is only used from the server, never from the client."

2. Your database might be readable by anyone in the world

Most Lovable apps use a service called Supabase to store data — customers, orders, messages, whatever your app deals with.

Supabase has a security setting called Row-Level Security, often abbreviated RLS. Think of RLS like the locks on the doors of your office: without locks, anyone walking past can come in. With locks, only people with a key can. RLS is what tells Supabase who is allowed to see which rows in your database.

Here's the catch: RLS is turned off by default when you create a new table. Lovable doesn't always turn it on for you. That means — even if you have a login screen — anyone in the world can sometimes read every row from every table in your database, just by knowing the right URL.

The business risk: Your entire customer list, every message they've sent, every order they've placed — exfiltrable in a single web request by anyone who looks. This isn't theoretical. Researchers and bad actors actively scan the internet for exactly this misconfiguration.

What to do (30 minutes, no developer needed if you're comfortable in dashboards):

• Log into Supabase → pick your project → open "Authentication" → "Policies" in the sidebar.
• For every table in the list, check whether RLS is enabled. The dashboard shows a green badge if it is.
• If it's not, click into the table, enable RLS, and add at least one policy. The simplest one for most apps is "users can only see their own rows" — Supabase has a one-click template for this called "Enable read access for authenticated users only" or "Enable insert/update for users based on user_id."

If you have more than five tables or your app has complicated permissions ("admins can see everything, free users can only see X"), this is the moment to ask a developer for an hour. Getting RLS wrong is worse than not having it on, because you'll think you're protected.

There's a single document that's worth reading slowly here: the Supabase Row-Level Security guide. It's written for developers, but the first half is readable as a founder.

3. Your login screen might be decorative

It's normal for an app to show a login screen, and to redirect users to "/login" if they're not signed in. But here's the thing: that's a user interface check — it only stops people from seeing the dashboard page. It doesn't always stop them from reading the data behind the dashboard.

In a properly built app, the data is protected too: even if someone tries to go around the login screen and request the data directly, the server refuses. In a vibecoded app, this second layer is often missing.

The business risk: Anyone who knows a tiny bit of how websites work can skip your login screen and download your data anyway. The login screen is a sticker on the door, not a lock.

What to do (1 hour, mostly with a developer):

• This one is hard to test yourself because it requires running specific web requests. Ask a developer friend to spend 30 minutes "hitting your API routes without a login token and seeing what comes back." Anything that returns real data when nobody's logged in is broken.
• For multi-customer apps (where each customer has their own "workspace"): make sure that the customer ID is looked up from the user's login, not sent by the browser. If your URL contains something like /workspace/42, ask a developer to confirm that user 42's workspace is actually user 42's, and not accidentally accessible to user 43.

If you can only do one of the eight gaps with a developer's help, do this one. It's the one that's hardest to spot from the outside and one of the most common causes of "data breach" headlines.

4. Your AI features have no spending limit

If your app uses AI — generating text, summarising things, answering questions — it's calling OpenAI, Anthropic, or another provider in the background. Each call costs you money.

The default in a vibecoded app is: anyone who lands on your site can hit your "Generate" button as many times as they want. No login required, or only a token gate. No cap on how big the request can be. No daily ceiling on your total spend.

This is fine on a quiet Tuesday. It is not fine the day a Twitter post about you goes viral, or the day a bot finds your endpoint and runs 100,000 requests in an hour to test it. Founders have woken up to five-figure bills from a single weekend.

The business risk: A bill that's bigger than your bank account. The industry has a name for this — "denial of wallet." OpenAI and Anthropic both let you set hard spending limits on your account, but it has to be done manually.

What to do (1 hour, mostly without a developer):

• Set a hard spending limit at the provider. Log into OpenAI → Billing → Usage limits → set a "hard limit" you can afford to lose if everything goes wrong. Same for Anthropic. Same for Google. This is the single most important safety net.
• Hide your AI features behind a login. A logged-out user shouldn't be able to use AI features on your app. Make this true in your app's UI — but also tell your developer to make it true on the server (see gap #3).
• Ask a developer to add "rate limiting" to your AI feature. Rate limiting means: one user can only use the feature, say, 30 times per hour. This takes a developer about an hour to set up using a service like Upstash. Without it, one bored user can drain your account.
• Cap how long the AI's response can be. Each AI call has a setting for "maximum response length." Most vibecoded apps don't set it, which means each call can cost ten times more than necessary. Ask your developer to set a reasonable maximum.

The OWASP Top 10 for LLMs lists this kind of unbounded AI use as one of the biggest risks for AI-powered apps. It's a five-minute read and worth doing.

5. You won't find out when something breaks

When something breaks in your app — a payment fails, a sign-up form silently errors, an AI feature stops working — how do you find out?

For most vibecoded apps, the answer is: a customer emails you. Sometimes a customer doesn't email and just leaves. Either way, you've already lost the moment.

The business risk: You spend three days running ads to a sign-up form that's been broken since Monday. Or your payment webhook silently fails for two weeks and you can't reconcile your invoices. You only ever find out about the problems users bothered to report.

What to do (1 hour, mostly without a developer):

• Install Sentry. Sentry is a service that watches your app and tells you (Slack, email, SMS) the moment something breaks. The free tier is plenty for an early-stage app. You'll find one-click installation guides on Sentry's website. If you have a developer helping you, this is a 15-minute task for them. If you don't, follow the Lovable guide for adding a Sentry integration.
• Add an "uptime monitor." This is a service that pings your website every 60 seconds and alerts you if it stops responding. Better Stack, Pingdom, UptimeRobot all have free tiers. Sign up, paste in your URL, choose where alerts go (Slack and SMS are best — email is too easy to miss).
• Pick one Slack channel where every alert lands (or one phone number for SMS). If alerts go everywhere, they end up going nowhere.

You can't fix what you can't see. This step turns invisible problems into ones you actually get to solve.

6. Every change you make is a coin flip

When you ask Lovable (or any AI tool) to make a change to your app, it edits the code and republishes. There's usually no "draft mode," no "preview the change before showing it to customers," no "automated test that the sign-up flow still works."

Which means: every change is a tiny gamble. Most changes are fine. Occasionally, a change breaks something — usually something you weren't expecting to be related — and you don't realise for hours or days.

The business risk: A change you made on Friday afternoon broke sign-up. You only find out on Monday morning when nobody has signed up over the weekend. You can't tell which change caused it because three things shipped.

What to do (a few hours with a developer, then it pays back forever):

• Get your code into GitHub if it isn't already. Lovable has a "Sync to GitHub" option. Use it. This gives you a history of every change, the ability to undo any change, and a place to add safety nets.
• Ask a developer to set up "CI." CI (Continuous Integration) is a robot that checks every change before it goes live: does the app still build? Does the type-checker still pass? Five or six basic tests that the most important pages still work? GitHub Actions is free and a developer can set this up in a few hours.
• Get "preview deploys." If you're hosting on Vercel or Netlify, every proposed change automatically gets its own temporary URL where you can click through the app before approving it. This alone catches most "I didn't realise this would break" moments.
• Know your "rollback" button. Vercel has a one-click "Instant Rollback" feature; Netlify has the same. Find it now, before you need it at 11pm on a Saturday. If your Lovable preview is your only deployment, ask about migrating to Vercel.

The first time a deploy breaks something and you can undo it in one click, you'll understand why this is on the list.

7. Your database changes are all in your head

When you ask Lovable to add a new feature, it sometimes adds a new field to the database. You also probably added a couple of fields manually in the Supabase dashboard. Maybe a co-founder added another one. After two months, nobody remembers which fields exist, which ones are required, what they're for, and whether the test environment matches the live environment.

This is called schema drift, and it's the slow-burn version of all the other gaps. It doesn't hurt today. It hurts a lot in six months.

The business risk: A developer you hire later can't tell what your database is supposed to look like, so they have to be twice as careful and ship at half speed. Or you accidentally test a new feature in one environment, push it live, and find out the live database is shaped slightly differently — and the feature breaks.

What to do (1–2 hours with a developer once, then a habit):

• Ask your developer to set up database migrations using the Supabase CLI. Every change to the database is then a small file in your code repo, applied automatically, version-controlled, reversible.
• After that's set up: stop changing your database in the dashboard. Treat the Supabase dashboard's "Table editor" as read-only for any column or table changes. All changes go through code from now on.
• Turn on automatic backups in Supabase. They're on by default on paid plans, but verify. Once a quarter, restore one of those backups to a test project and confirm it actually works. A backup you've never tested is a hope, not a backup.

This is the gap most founders postpone the longest. Don't. Every month without a migration story makes the cleanup more expensive.

8. You probably don't have your legal scaffolding in place

If you take on any user from the EU — and you will, on day one, often without realising — you legally need: a privacy policy, a way for that user to delete their data, a description of what you do with their information, and (if you use tracking cookies) a cookie banner.

Similar rules exist in California, Brazil, the UK, and an expanding list of US states.

The business risk: For an MVP, the threat usually isn't a regulator's fine. It's a user emailing to ask for their data to be deleted, you not being able to do it, them tweeting about it, and your growth stopping. It's also that many enterprise buyers won't even start a conversation with you if you don't have a privacy policy at your domain.

What to do (2–3 hours, no developer needed):

• Get a privacy policy at yourdomain.com/privacy. Termly and Iubenda generate one in 15 minutes from a short questionnaire and cost less than your monthly OpenAI bill. Link it from the footer of every page.
• Get a terms of service at yourdomain.com/terms from the same tool, while you're there.
• Build a "delete my account" button that actually deletes the user. Test it with a real account. If your delete button just logs the user out, that's not a delete button.
• Cookie banner — if you're using Google Analytics, Meta Pixel, or any marketing tracking pixel, you need one. Cookiebot or a simple Lovable-built banner are both fine.
• Write one paragraph in plain English about what you do with user data. Put it on a page called /data. This doubles as marketing — "we don't train AI models on your data" is something serious customers care about in 2026.

The whole legal scaffolding for an MVP usually costs less than €200 a year and an afternoon of your time. It's the lowest-effort, highest-trust-return item on this list.

The 40-minute audit you can run today

Pour yourself a coffee. Open your laptop. Run through this in order.

1. Open your live site in Chrome → right-click → Inspect → Sources tab. Search for sk_, service_role, and your AI provider's name. Anything found = gap #1.
2. Open the Supabase dashboard → Authentication → Policies. Any table without an RLS policy = gap #2.
3. Try to sign up with a fake email and password. Then open the URL of your dashboard in an incognito window. Can you still see anything? Gap #3.
4. Log into your OpenAI / Anthropic account → Billing → Usage limits. No hard limit set = gap #4. Set one before you close the tab.
5. Ask yourself: when did your app last break, and how did you find out? "A user told me" or "I have no idea" = gap #5.
6. Look at your code in GitHub. Is there a .github/workflows/ folder with anything in it? No = gap #6.
7. Count how many times in the last month you changed something in the Supabase dashboard directly. More than zero, and you haven't migrated to migrations yet = gap #7.
8. Open your website's footer. No privacy policy link? No delete-account button anywhere? Gap #8.

Each "yes" is a real risk. Most are fixable in an afternoon. A few — particularly gaps 2, 3, and 6 — usually need an hour or two of a developer's help. None of them require you to throw away what Lovable built for you.

In what order should you fix things?

If you're going to do this yourself, in order of urgency:

1. This week: set the spending limit on your AI provider (gap #4). This is two clicks. Do it before anything else on the list. A runaway AI bill ruins a startup faster than any other failure mode here.
2. This week: search your bundle for leaked keys (gap #1). If anything's there, rotate it immediately.
3. This week: turn RLS on for every table in Supabase (gap #2). Get a developer for an hour if you have more than five tables or any complex permissions.
4. This week: install Sentry and an uptime monitor (gap #5). You can't fix what you can't see.
5. Within the first month: put the legal scaffolding in place (gap #8). It's cheap and it unlocks enterprise conversations.
6. Within the first month: ask a developer to harden the auth boundary (gap #3) and set up CI + preview deploys (gap #6).
7. Within the first quarter: move database changes to migrations (gap #7).

This sequencing isn't aesthetic. It's the order in which gaps tend to bite, weighted by how badly they hurt when they do.

What "ready to launch" really means

Ready-to-launch isn't perfect. It's "the failure modes are known, bounded, and recoverable."

A ready-to-launch app can lose its database and be back inside an hour. It tells you when something breaks before customers do. It can roll back a bad change with one click. Its data isn't readable by strangers. The AI features can't drain your bank account overnight. You can confidently put a paying customer's name on the homepage as a logo.

Closing these eight gaps will not slow you down forever. The first time you do it, it takes a week. After that, it's the way you build.

The promise of vibecoding is real. You can ship a real product faster than at any point in software history. You can be a non-technical founder with a real software business in less time than ever before. What changes is the work between demo and launch — and the work between demo and launch is what this post is about.

How we help

QwertyBit specialises in taking vibecoded apps from "great demo" to "safe to launch" in two to three weeks. We run exactly this audit live, on your specific app, then we close the gaps you don't want to close yourself. You keep all the speed of having built it in Lovable; you don't keep the silent landmines.

If you've built something in Lovable, Bolt, or v0 and you're staring at the gap between "preview URL" and "real domain with paying customers," book a free discovery call. Forty minutes, we run the audit live on your app, and you leave with a prioritised punch list whether you work with us or not.

While you're here, our step-by-step MVP playbook covers what to build before you start coding (vibe or otherwise), and our piece on choosing the right SaaS architecture covers the longer-term version of "is this thing going to scale" — both useful follow-ups to this post.

The vibecoding revolution is real. The "launch" part of "vibecoded to launch-ready" is still where the work is. You don't have to do it alone.