Built your app with Lovable or Bolt? Check these 10 things before real users sign up

AI app builders have made the first 80% of a product genuinely fast. You describe the app, Lovable, Bolt, Replit or Cursor writes it, and a few days later you have something that logs people in, saves data and looks finished.

The trouble starts when strangers use it. A founder on r/vibecoding summed it up in one line: three weeks to build the MVP, five months to fix it. Another thread title we keep seeing in different forms: "Built an MVP in 10 days. Now I'm scared to deploy it."

That fear is reasonable. In February 2026 a researcher found that one app built on Lovable exposed data on more than 18,000 users because its database rules were missing. In September, security firm UpGuard reported that around 16,000 Supabase-hosted databases were exposing personal data, mostly through misconfiguration. None of this means the tools are bad. It means the tools build what you ask for, and nobody asked for the boring parts.

Here is the checklist we run before an AI-built app goes in front of paying users. You can do most of it yourself in an afternoon.

1. Turn on row-level security for every table#

Most AI builders use Supabase for the database. Supabase gives your app a public "anon" key that ships inside the browser. That is fine and intended, but only if every table has row-level security (RLS) switched on with rules that say who can read and change which rows.

Without RLS, anyone who opens the browser's developer tools can copy that key and read your whole users or orders table.

How to check: open the Supabase dashboard, go to the table editor and look for any table marked as unrestricted. Then test it properly: log in as one user and try to load another user's record by changing the ID in a request. If it loads, your rules are wrong.

2. Find every secret key in the frontend#

Search your code for anything that looks like sk_, service_role, secret or an OpenAI, Stripe or Resend key. If it appears in a file that runs in the browser, assume it is already public.

The Supabase service_role key is the dangerous one. It skips every RLS rule. It belongs only in server code or edge functions. The same goes for your Stripe secret key and any AI API key; a leaked one can turn into a surprise bill within hours.

If you find one, moving it is not enough. Rotate it in the provider's dashboard so the old one stops working.

3. Check who can call your AI and email functions#

If your app calls an AI model or sends email through a serverless function, ask: what stops a stranger from calling that function ten thousand times?

At minimum, the function should check that the caller is logged in, and it should limit how often one user can call it. This is the cheapest insurance you will ever buy, because these endpoints are paid by the request.

4. Make payments survive the real world#

Payment flows look fine in testing and fail quietly in production. The usual culprits:

• Webhooks are not verified. Your server should check Stripe's (or Razorpay's) signature on every webhook, or anyone can fake a "payment succeeded" event.
• Webhooks are not idempotent. Providers retry. If the same event arrives twice, you should not create two subscriptions or send two receipts.
• Access is granted on the success page. The redirect after checkout is not proof of payment. Grant access when the verified webhook arrives.

5. Lock down file storage#

Profile photos, invoices and uploaded documents usually live in a storage bucket. AI builders often create these buckets as public because it makes images load easily. That is fine for marketing images. It is not fine for anything a user uploads.

Make private buckets the default and use short-lived signed links for anything personal.

6. Set up real email sending#

Supabase's built-in email sender is meant for testing and is heavily rate-limited. If your sign-up, password reset or magic-link emails go through it, they will start failing as soon as more than a handful of people sign up.

Connect a proper email provider, set up SPF, DKIM and DMARC records on your domain, and send yourself a test from each flow. Check the spam folder too.

7. Turn on backups and practise a restore#

Ask yourself what happens if a bad migration deletes a column of customer data tonight. On Supabase, daily backups and point-in-time recovery depend on your plan, so check what yours includes. Then restore a backup into a test project once, so you know it works before you need it.

8. Add error tracking and basic logs#

When a user says "it didn't work", you need to see what happened. Add an error tracker such as Sentry to both the frontend and your server functions. It takes about twenty minutes and turns guesswork into a stack trace.

9. Make sure Google can actually read your pages#

Many AI builders produce single-page apps that render everything in the browser. Google can render JavaScript, but it is slower and less reliable, and many AI crawlers do not run JavaScript at all. A founder on r/lovable asked whether Lovable makes SEO "hard" after spending months on a site that was barely indexed. Often the answer is yes, for the marketing pages.

The fix is usually to keep the app as it is, but serve your homepage, pricing and content pages as static or server-rendered HTML with unique titles and descriptions. We wrote more about this in SEO for service businesses.

10. Own your code, domain and accounts#

Before launch, make sure:

• The code is exported to a GitHub repository you own.
• The domain is registered in your name, not a freelancer's or the builder's.
• Supabase, Stripe, email and hosting accounts are under your company email, with a second admin.

This matters for more than security. Several Lovable users on Reddit have complained about credit costs climbing once they had real traffic. If you own the code, moving hosting later is a weekend job instead of a rebuild.

Should you fix it or rebuild it?#

Most AI-built MVPs do not need a rewrite. If the data model makes sense and the problems are the ones above, a focused clean-up is faster and cheaper. A rebuild makes sense when every new feature breaks two old ones, when nobody can explain how the data fits together, or when you are about to raise money and need a codebase a hired engineer will not be afraid to open.

A useful rule from one r/startups thread: get a developer involved when you start taking money for what your code does.

The short version#

AI builders are a great way to get to a working product. Before real users arrive, spend a day on the unglamorous parts: database rules, secret keys, payments, email, backups and ownership. That day is the difference between a launch and an incident.

If you would rather have someone else run this audit, book a free strategy call. We will go through your app with you and tell you honestly whether it needs a clean-up, a partial rebuild or nothing at all.