Five signs your Lovable or Bolt app isn't ready for real users

Your Lovable or Bolt app isn't ready for real users if one customer might see another's data, your keys are visible in the browser, every change breaks something else, you can't undo a bad update or restore lost data, or you find out about errors from your users.

Why do Lovable and Bolt apps break after launch?

Both tools are built to get you from an idea to a working app quickly, and they do that well. Lovable generates a React front end with a Supabase backend. Bolt generates apps in the browser, often deployed straight from the editor, and what sits behind the front end varies from project to project.

What neither tool can do is decide your security model, your backup plan or your release process for you. Those things are not part of a prompt, so they often don't get built. The app behaves in a demo because a demo has one user, no money and no real data. This is not a criticism of either tool. It is what a prototype tool is for.

The five signs below are the ones we look for first. Each one is invisible on screen and obvious once someone reads the code.

Can one customer see another customer's data?

This is the most serious sign, and the hardest to spot yourself. The app looks fine when you log in, because you only ever see your own account.

The question is what happens when someone signed in as customer A edits a number in a web address or a request and asks for customer B's record. If the server doesn't check who is asking, it simply hands the record over.

In Lovable apps, this usually comes down to Supabase row-level security. These are the rules that decide which rows of each database table a signed-in user is allowed to read or change. They are often missing or too permissive, because the demo worked without them. In Bolt apps, the common version is a front end with no real sign-in or data layer behind it, so the "login" is only on screen.

A simple test: ask someone who didn't build the app to log in as one customer and try to see another. If nobody has tried, treat it as a risk.

Are your keys visible to anyone who views the page?

Apps talk to other services, such as payments, email and AI models, using secret keys. Those keys belong on the server. If they are in the code that runs in the browser, anyone who opens the page source can copy them and use your accounts.

This happens easily with AI-built apps. A prompt asks for a feature that calls a payment or AI service, and the quickest working answer puts the key right next to the button. In Bolt projects in particular, keys pasted into client code are a common finding. In Supabase projects, the dangerous one is the service-role key, which bypasses every data rule you have.

If you have been told your keys are exposed and don't know how bad that is, assume it is worth checking this week, not next quarter.

Does every change break something else?

When you ask the builder for a new feature and an old one stops working, that is a sign there are no automated tests. A test is a small piece of code that checks something still works, such as sign-up or checkout, every time the app changes.

Without tests, the only way to know that paying still works is to try it by hand after every change. Nobody does that every time. So the breakage reaches your users first.

A related sign: payments succeed in Stripe but the app doesn't update, or the other way round. That usually means the app has no safe way to handle a payment message that arrives late, twice or not at all.

Can you undo a bad update, or restore lost data?

Ask yourself two questions. If you push an update tonight that breaks the app, can you put the previous version back in under ten minutes? And if your database was deleted, could you restore yesterday's copy by tomorrow morning?

Many AI-built apps can do neither. There is one environment, which is live. There is no separate place to test changes with its own keys. Changes to the database are made directly rather than through migrations, which are scripts that record each change so it can be repeated or reversed. Backups may exist, but nobody has ever tried restoring one.

None of this matters until the day it matters a great deal.

Do you find out about errors from your users?

If the first you hear of a problem is a customer email, the app has no error tracking. Errors happen in every app. The difference in a production system is that they are recorded with enough detail to fix, and someone is told within minutes.

If your app uses AI features, the same applies to cost. Without tracking and spending caps, a feature that loops or gets heavy use can run up a model bill you only see at the end of the month.

What should you do if you recognise these signs?

Start by measuring, not panicking. Our self-check asks eight plain questions and gives you a score and a straight recommendation. If nothing worries you and no real users or money are involved yet, keep building.

If some of it sounds familiar, our pages on fixing a Lovable app and fixing a Bolt app go into the detail for each tool. The usual next step is a two-day triage for $349, where a senior engineer reads your code and returns the five risks that matter most, an indicative range for fixing them and a recommendation. Half the fee is credited against any sprint that follows within 30 days.

All five signs are fixable without a rebuild in most cases. A stabilisation sprint, from $2,500 over one to two weeks, closes what blocks launch. A production hardening sprint, from $6,000 over three to five weeks, covers the full list. You can read the whole offer on our AI product rescue page.