A Lovable prototype becomes a production app once four gaps are closed: row-level security in the database, real logic in place of prompt guesses, proper testing, and a clean release to your own host. Lovable is very good at getting you to a prototype. It does not get you to production, and the distance between the two is where most of the engineering lives.
The reason a prototype demos well and then breaks is simple. Demos follow the happy path. Production has real users doing things you did not script, and the parts that hold up under that are exactly the parts prompts do not build reliably.
Gap 1: Row-level security
This is the one that matters most. Lovable builds on Supabase, and Supabase uses row-level security policies to control who can read and write each row of data. Generated policies are frequently too loose, which means a signed-in user can fetch or change records that belong to someone else, just by adjusting a request.
Closing this gap means writing explicit policies on every table, for every role, and then testing them from each role's point of view: can a buyer read another buyer's orders? Can a user edit a listing they do not own? Until every answer is no, the app is not safe to launch.
Gap 2: Real logic instead of prompt guesses
Ask Lovable to "handle the payment" and you get something that looks complete. Look closely and the error handling is thin: what happens when the card is declined, when the webhook arrives twice, when the payout fails, when the user closes the tab mid-checkout.
Production logic is code with those cases handled. This usually means taking the fragile generated version and rewriting the important flows by hand: payments, permissions changes, anything that moves money or data between systems.
Gap 3: Testing
A prototype is tested by clicking through it once. A production app needs the main user journeys checked deliberately, on real screen sizes, including the paths where things go wrong. Sign-up with an email already in use. Submitting a form with a field missing. Losing connection mid-action.
This does not need a huge test suite for a first launch, but it does need someone to work through the app as an adversary rather than a demo-giver.
Gap 4: A clean release
Prototypes run on preview URLs with test keys. Production needs:
- Environment variables set for real: live payment keys, real API credentials, correct URLs
- Error monitoring, so you find out about failures before your users tell you
- A checked build deployed to your Vercel or Netlify account
- The GitHub repository handed to you, with a short note on how it is put together
What stays from the prototype
Usually more than you would expect. The screens, the component structure and the general shape Lovable produced are typically kept. The work is concentrated in the backend and the seams. It is a hardening pass, not a rebuild, and for a focused app it takes one to three weeks on top of the prototype.
What we do
At MarkLogix this hardening pass is most of what a Lovable build involves. We take the prototype, close the four gaps, ship a tested release to your host, and hand you the repository. If you have a Lovable project that needs to become real, send us the link and you will get a written view of the work, or start a project and we will scope it properly.