Lovable to production: the 12 checks we run before real users arrive

What "production ready" means for a generated app

A Lovable or Bolt app is production ready when a stranger with a second account cannot read your first account's data, a failed webhook cannot double-charge anyone, and a long job cannot freeze the page. Those three failures are what we find most often in generated code, and the twelve checks below are how we look for them.

Generated apps are good at the part you can see. The screens exist, the flows work for the person who built them, and the demo lands. The gaps sit underneath, in the parts no prompt asked for: row-level security that was never switched on, a secret that ended up in the browser bundle, a retry that never happened. The pattern is the same whether the generator was Lovable, Bolt or a weekend of copy-pasting from a chat window.

Our list comes from one job in particular. An enterprise knowledge platform came to us as a live proof of concept, already used by real people, and had to become something an enterprise security team would sign off. Over six months and 1,145 billed hours it gained multi-tenant workspaces on Supabase row-level security, background conversion for PDF, DOCX and PPTX files, prompt caching with a context budget, and a human approval step before the AI wrote anything back. Every one of those became a check we now run on every MVP.

The 12 checks

Run these in order. The first six are security and decide whether the app can face the public at all; the rest decide whether it survives the first month of real traffic. Each row gives the check, why generated code tends to fail it, and a way to verify it in about five minutes.

Checks 6, 7, 8 and 9 are the ones the other published checklists leave out, and they are the ones that cost the most to retrofit. Tenant isolation decides the shape of every query. Background jobs decide the shape of every upload. The cost controls and the approval step decide whether the AI feature is a product or a liability.

Keep, fix or rebuild: how we decide

We keep code when the data model is sound and the gaps are in the plumbing. We fix when the model is close but the security layer is missing. We rebuild when the tables encode the wrong assumptions, usually single-tenant data under a multi-tenant product. The decision comes out of a written code audit, with the reasoning beside each module.

A keep verdict is more common than people expect. A generated React front end with sensible components is worth keeping; so is a Supabase schema where the relationships are right and only the policies are missing. A rebuild verdict is usually about the data layer rather than the UI, and it is usually partial: new tables for tenancy and jobs, with the screens pointed at them.

The audit itself takes about a week on an MVP of typical size. It covers the twelve checks above, the dependency list, the deployment and whatever the founder is most worried about. It ends with a written plan that names which modules to keep, which to fix, which to replace, and in what order, so the app keeps running while the work happens.

What this looked like on an enterprise knowledge platform

The knowledge platform we took to production had passed its demo and was already answering questions from company documents for real users. It failed checks 1, 6, 7, 8 and 9 in the form most generated apps do: the data was there, the users were there, and the walls between them were in application code rather than the database.

Tenant isolation moved to Supabase row-level security, with policies on every table and a test that signed in as a second workspace and tried to read the first. Document conversion moved out of the upload request into background jobs, one converter per format, with retries, so a large slide deck stopped freezing the person who uploaded it. Each chat request gained a context budget split between history, retrieved passages and the answer, and prompt caching on the stable part of each prompt. Finally, every change the AI proposed to the knowledge base went to a person first, with the evidence beside it.

The proof of concept stayed live for the whole six months. That was the constraint that shaped the order of work: policies first, because they could be added without changing the screens; then jobs; then the cost controls; then the approval flow. The client's review afterwards said the thing we care most about, that a vague problem went in and a scoped plan with the trade-offs named came back.

Questions founders ask about this list

Is Lovable production ready out of the box? The code it generates can be. The defaults are not. Row-level security, webhook verification, background jobs and tests have to be asked for or added afterwards, and most people do not know to ask during a demo.

Do I have to leave Lovable to fix these? Not for most of the list. Policies, validation and webhook checks can be added inside the generated project. Background jobs and multi-tenant data models usually mean adding infrastructure the generator did not set up, which is where a rebuild of the data layer starts to make sense.

How long does the audit take? About a week for an MVP of typical size. The written keep, fix or rebuild plan is the deliverable; it is yours whether or not we do the build.

What does it cost? The audit is the discovery sprint, from $2,500. A production build is priced against the plan, from $6,000, in increments you review as they ship.

My app has no AI feature yet. Does the list still apply? Checks 1 to 7 and 10 to 12 do. Checks 8 and 9 apply the day you add a model call, which for most generated apps is soon.

What we would do on your project

Send us the repository and the Supabase project, or a link to the deployed app and a few minutes on a call. We run the twelve checks, write down keep, fix or rebuild per module, and give you the order of work with the app staying live throughout. The audit is the discovery sprint, from $2,500. Book a free architecture call and bring the question that is keeping you up; or read how the same work went on the enterprise knowledge platform, and what the Lovable to production service covers.