AI app builders are very good at the part of software you can see. You describe a product, and an hour later there is a working interface with sign-up, a dashboard and a checkout button. That is real progress, and it is why so many founders now arrive with a prototype instead of a slide deck.
The trouble starts when real users, real payments and real data arrive. I rebuilt PropVPS, a hosting platform, from a Lovable prototype into a live product, and I get asked the same question often: what actually has to change?
Here is the honest list, in the order I would fix it.
1. Who can read and change what
This is the big one. Most Lovable apps use Supabase, where the browser talks to the database directly and row-level security rules decide what each user may see. If those rules are missing or too loose, any signed-in user can read other customers' records by changing a request in their browser.
Nothing about the app looks broken when this is wrong. The demo works. The problem only shows when someone goes looking.
What to check:
- Every table has row-level security turned on, with rules written for it.
- Rules are tested by signing in as two different customers and trying to reach each other's data.
- Admin-only actions are enforced on the server, not just hidden in the interface.
Supabase documents how this works in its row-level security guide.
2. Secrets that ended up in the browser
Anything shipped to the browser is public, however it is named. Builders sometimes wire a payment, email or AI key straight into front-end code because that is the fastest way to make the feature work.
Move every secret key to the server: an edge function, an API route or a small backend. Then rotate the keys that were exposed, because you cannot know who has already copied them.
3. Payments that only work on the happy path
A checkout button is the small part of a billing system. The larger part is what happens afterwards: renewals, failed cards, cancellations, refunds and disputes. Stripe reports all of these through webhooks, and a prototype often handles one event or none.
On PropVPS a successful payment has a real consequence: a server gets created. So the webhook handling had to be right before anything else could be trusted. If a server cannot be created after payment, the customer is refunded automatically, so nobody pays for something they did not get. Stripe's webhook documentation covers the mechanics.
4. Work that takes longer than a request
Prototypes do everything inside the request: the user clicks, the app calls three services, the page waits. That holds up until one of those calls takes thirty seconds, or fails halfway through.
Creating a server, generating a long AI response or importing a file should be a background job: the request records what needs doing and returns at once, a worker does the job and retries on failure, and the interface shows progress. PropVPS provisions servers this way and pushes live status updates to the customer's dashboard.
This is also the point where many apps outgrow a builder, because background workers need somewhere to run.
5. Login, roles and account safety
Sign-up and login usually work out of the box. What is often missing:
- Roles that are enforced on the server
- Email verification and a sane password reset flow
- Two-factor login for accounts that control money or infrastructure
- Rate limits on login and sign-up
PropVPS customers manage live servers, so two-factor login is built in, and server credentials are encrypted before they are stored.
6. A safe way to change things
A prototype has one environment: the live one. Production needs a little more:
Separate test and live data
A staging copy with its own database and test payment keys, so you can try changes without touching customers.
Put the code in your own repository
Even if you keep building in Lovable, sync to GitHub so changes are reviewable and reversible.
Back up the database
Turn on automated backups, then restore one once so you know it works.
See errors before customers report them
Add error tracking and basic uptime alerts.
What you can usually keep
Most of what you see. Page layouts, components, copy and the overall flow tend to survive. On PropVPS the look and the product thinking carried over. What got rebuilt was the machinery underneath: billing, provisioning, credentials and the support desk.
That is the useful way to think about it. The prototype answered "what should this product be?" Production engineering answers "what happens when it goes wrong?"
When to leave the builder
You do not have to leave at all. Plenty of products can launch on the builder once the six areas above are fixed. Move to your own repository and hosting when you need background workers, custom infrastructure or several engineers in the code.
If you want a second pair of eyes before launch, this is exactly what my prototype to production work covers: a written review of these areas, then the fixes in priority order.