Why Your Lovable Prototype Isn't Ready for Real Users

A Lovable prototype is usually closer to ready than people fear and further than they hope. The UI is fine. The UI is almost always fine. What isn’t ready for real users is the stuff nobody clicks on in a demo, and it tends to be the same five or six things in every app we open.

This is roughly the order we check them in during the first hour of an audit, with the commands we actually run.

Who can read your tables

Open the Supabase SQL editor (or ask Lovable to run it for you on Cloud) and run this:

select tablename, policyname, cmd, qual
from pg_policies
where schemaname = 'public';

You’re looking for a qual of true. That means the policy lets anyone matching the role read every row, and in a Lovable app the role is often anon or authenticated. Your anon key ships inside the frontend bundle by design, so “anyone” really does mean anyone with a browser console. Then look for tables that don’t appear in the output at all, because RLS enabled with no policies means nobody can read them, and RLS disabled means everybody can.

Lovable’s security scan catches some of this now. It doesn’t understand your business rules. It can’t know that orders should only be visible to the customer and the shop owner, not to every logged-in user. We wrote a whole post on what the Lovable security scan won’t catch, and this is the biggest item on it.

The 1,000 row ceiling

This one isn’t a security problem, it’s a lying-dashboard problem, and I love it because it’s so quiet.

Supabase’s API returns at most 1,000 rows per request by default. A Lovable-generated admin page that does select('*') on your users table and counts the results will happily show 1,000 forever.

We had a founder who celebrated hitting 1,000 signups. Screenshot on LinkedIn and everything. Three weeks later the number was still exactly 1,000 and they assumed growth had stalled, ran ads to fix it, and asked us why the ads weren’t working. The real count was 1,640. The ads were working fine. The admin page just couldn’t count past the default limit.

Fix it with a proper count (select('*', { count: 'exact', head: true })) and real pagination with .range(). Every list in your app that can grow needs this, not just the admin page.

Edge functions anyone can call

Lovable likes to put AI calls, Stripe calls and email sends in edge functions, which is the right place for them. Then check supabase/config.toml for verify_jwt = false. Sometimes that’s on purpose, because a Stripe webhook can’t send a user’s JWT. Often it was set to make an error go away during the build and never set back.

An edge function with no JWT check that calls OpenAI is a public endpoint that spends your money. Someone finds the URL in the network tab, puts it in a loop, and you find out from the invoice. If a function really needs to be public, it needs its own check: a webhook signature, a rate limit, something.

Emails that never arrive

If you moved off Lovable Cloud to your own Supabase project and never set up custom SMTP, your app can send 2 auth emails per hour, only to your own team’s addresses. Signups work in testing because you’re on the team. They fail for everyone else. The full list of email traps is in our Lovable email post, but if you only do one thing, set up SMTP before launch.

Nobody finds out when it breaks

Prototypes swallow errors. A failed insert shows a toast for two seconds, or nothing, and the user leaves.

Put Sentry on it. The React SDK takes about ten minutes, the free tier is plenty for an early app, and the first week usually shows a couple of errors you didn’t know about. I’m not a fan of LogRocket for small teams, session replay is great until you realise you’re recording people typing into forms and need to think about what you store. Sentry plus decent Supabase logs is enough for a while.

Files and backups

Phones upload 4 to 12 MB photos. A prototype stores them as-is, serves them full-size in a 64px avatar circle, and burns through storage and bandwidth. Resize on upload. If you’re on Lovable Cloud, this is usually the first wall people hit, and we covered it in the storage quota post.

Then find out what your plan actually backs up, and whether you’ve ever restored from it. Most founders have never tried. “We have backups” and “we can restore” are different sentences.

What can wait

A lot of production checklists tell you to set up staging, CI/CD, load testing and a CDN before launch. For a Lovable app with its first hundred users, most of that can wait. Lovable already deploys for you and serves from a CDN. Staging is nice and nobody uses it at this size.

Do the RLS check, the row limits, the edge function auth, email and error tracking. That’s maybe two days of work for someone who knows Supabase, and it covers most of what actually goes wrong in the first month.

That’s what the audit at the start of our process is: those checks against your real project, a written list ranked by how bad each one is, and fixes. Prices are on the pricing page. Or send us the project and we’ll tell you what we’d fix first.