Your Lovable app runs. Seven things stand between it and a paying customer.
You described an app and got one. It loads and saves, and the people you have shown it to can use it. Now you want to charge for it, and the questions arriving are ones the builder never asked you.
The gap is the same whether it came out of Lovable, Bolt, v0 or Replit, and it is not in the code they write. Nobody generates the second database, the migration files, or the thing that wakes you up when it falls over.
The short answer
A generated app usually works. What comes with it is one environment that is also production, a database whose shape changes in place with nothing recording the change, access rules that were never switched on, keys sitting in the browser, and nothing at all that tells you when it breaks overnight. Closing that list is days of work, none of it a rewrite, and all of it belongs before the first customer who is not you.
What is missing on the day it looks finished.
- 01
There is one environment and it is production
The preview you are looking at and the app your customers use share a database. A change to a table happens underneath whoever is signed in at that moment. When you want to try something, there is nowhere to try it.
What you want is a second project with its own database and its own keys, and a rule that nothing reaches the live one until it has run in the other. Doing it before launch takes an afternoon. Do it afterwards and you are moving live customer records while people are using them.
- 02
Nothing tells you when it breaks
An app with no error reporting says nothing at all when it fails on somebody else’s machine. The screen goes white, the customer leaves, and no record anywhere shows that it happened.
Error reporting, a check that the URL still answers, and an alert that reaches your phone. It is an afternoon with Sentry and a hosted uptime monitor, and it is what stands between finding a fault yourself and reading about it at the top of your reviews.
- 03
The database answers to anyone until you switch it on
Supabase hands your app a public key on purpose, and that key is meant to be public. What decides who sees which rows is a row-level security policy on each table. A table with no policy, and row-level security switched off, returns everything in it to anybody signed in.
You will not find this by using the app, because while you were building it there was one account and every row belonged to you. It shows up the day the second customer signs in and reads the first one’s records.
- 04
Your keys went out with the page
Anything the browser can read, your customers can read, and that includes the key you handed it to call a model or a payment provider. Open the site, open the network tab, and it is sitting in a request. Somebody will find it with a scanner long before anyone finds it by looking.
Those calls belong behind a server function, where the key lives in an environment variable your customers never receive. While you are moving them, rotate whatever has already been out on the internet, because a key that has been public has to be treated as copied.
- 05
The database changes shape with no way back
Editing a table in the builder changes it in place. No file records what changed, nothing applies the same change to a second environment, and there is no way back to how the table was last week.
A migration is a numbered file in the repository, applied in order, run the same way everywhere. With those in place a change is something you can read before it runs and undo after it has, and somebody new can rebuild your whole database starting from an empty one.
- 06
Nobody outside the builder can work on it
While the code lives only in the tool that generated it, your options for getting help are whoever is willing to work inside that tool, at whatever it costs next year.
Connect it to GitHub on the first day, before there is anything much to move. It costs nothing, and it leaves you holding a history you can read and an app that outlives the company that generated it for you.
- 07
The bill grows with traffic, not with revenue
Generated apps call models per request, with no cache and no ceiling. A page that summarises something every time it loads costs you money whether or not the person reading it ever pays. Put a hard cap on the account, cache the answers that do not change between visitors, and know the monthly figure before you spend anything on getting people there.
Run these against your own build.
Every one of them can be done today, without us, on the app as it stands. A bad answer to any of them is a piece of work, and you would far rather meet it here than in a review.
- 01
You have somewhere to test that is not live
Name the database your preview writes to, and the one your customers write to.
Bad answerThey are the same database.
- 02
A second customer cannot read the first
Make two accounts. Signed in as the second, ask the API for a record belonging to the first, by its id.
Bad answerAnything comes back other than an error.
- 03
No secret reaches the browser
Load the live site, open the Sources panel, and search the built JavaScript for the strings below.
sk- sk_live service_role eyJBad answerAnything beyond the publishable key you meant to be public.
- 04
Schema changes are recorded somewhere
Find the file that describes the last change you made to a table.
Bad answerThere is no file, because the change was made by clicking.
- 05
Something is watching it
Break the app on purpose in a copy, and see what reaches you.
Bad answerNothing reaches you.
- 06
You own the code
Clone the repository to your own machine and run it locally with your own keys.
git clone <your-repo> && cd <your-repo> && npm install && npm run devBad answerThere is no repository, or it will not start outside the builder.
- 07
A restore works
Restore last night’s backup into an empty database and sign in against it.
Bad answerThere is no backup, or it comes back without the data.
When this sheet is the wrong one
Skip the lot of it if nobody is paying you yet and there are under a dozen people in there. Every item on this sheet costs days, and none of it makes anyone want the thing. Put it in front of people first, and come back the week somebody hands you money.
Asked most often.
- Is Lovable production ready?
- The code it writes can run in production. What arrives is a working app, and a running business needs more: a second environment, migrations, error reporting, and access rules somebody has switched on. You are looking at days of work, and almost none of it is a rewrite.
- Can you export the code?
- Yes. Lovable, Bolt and Replit all connect to a GitHub repository and v0 hands you the files. Do it before you need it, because the day you need it is usually a bad day already.
- Does it have to be rebuilt from scratch?
- Rarely. The screens and the data model usually survive. The work sits in what was never generated: environments, migrations, access rules, payment paths that survive a failure, and something watching the whole thing.
- How long does it take to get one live?
- For a build that already works on screen, we would plan for one to three weeks to a first release. An iOS app adds App Review on top, and we budget for more than one attempt at it.
- Is Supabase safe to use for a real product?
- Yes, and plenty of live products run on it. The part that has to be done deliberately is row-level security, one policy per table, because an empty policy list means every signed-in person sees everything.