Teardown: Would a Lovable Weekend Project Survive Monday?

The Monday failure is predictable. A weekend app built in Lovable has a clean form, a Supabase table, a model call, maybe a Stripe button, and enough polish to make the builder trust it. Then a second user signs in and sees a row they should not see. Or an Edge Function accepts a client-controlled user ID. Or the model fails after the database write and the UI reports success anyway.

This teardown keeps the article because it is the tangible version of the pivot. The production-readiness checklist tells readers what the gate is. This piece shows how a real builder would inspect one generated app without pretending the tool is the problem. Lovable's security documentation now includes built-in security scans, API key protection, database access checks, dependency audits, and security views. Supabase's current docs say RLS must be enabled for exposed schemas and distinguish publishable keys from secret keys. Those are useful rails, but rails do not prove the app's business logic is safe.

The review should feel adversarial without being theatrical. Do not ask whether the app is clever. Ask whether the main workflow completes for a non-admin user, whether data access is scoped, whether every external call leaves a trace, and whether the failure copy tells the truth.

A generated app usually works for its creator. That proves almost nothing about production. The owner account often bypasses the policy problem because the owner created every row, owns every project, and has every token in their local environment. The first serious teardown creates a second account and runs the workflow from that account with no elevated privileges.

The second-user pass should test reads, writes, updates, deletes, storage, and any API route that touches user data. In Supabase, RLS controls row access while grants control role access. Both need to be intentional. A table with RLS disabled in an exposed schema is a launch blocker. A policy that checks auth.uid() on reads but not writes is another. Storage needs the same treatment because public file URLs often escape the mental model people have for database rows.

The reviewer should not stop at schema inspection. Open the app in a browser, perform the primary action, capture the trace, then try to fetch or mutate another user's data. If the app uses Edge Functions, inspect whether the function trusts client-supplied ownership fields. If it uses a model to choose an action, inspect whether the server revalidates the action before writing. The model can suggest. The server has to enforce.

Lovable's security view is useful because it gives builders a place to see scanner findings instead of pretending generated code is safe by default. The mistake is treating a green scanner state as a product decision. A scanner can flag exposed keys, dependencies, or obvious data-access issues. It cannot know that a draft invoice should be invisible to a contractor, that a workflow should never email a customer twice, or that a failed import must keep the original file.

That is why the teardown pairs scanner output with workflow evidence. For every finding, ask which user action it touches and what harm follows. A missing RLS policy on a table that stores public templates is different from a missing RLS policy on customer financial data. A dependency warning in an unused path is different from a vulnerable package in an upload handler. The goal is not to lower the count. The goal is to remove paths where a normal user can create damage.

This is also where generated apps need explicit business rules. If the prompt says 'users can manage their projects,' the code still needs an ownership rule. If the UI hides an admin action, the server still needs an authorization check. If the model labels a record as safe, the application still needs deterministic validation for the fields that drive side effects.

The article is viable because it gives the site a recurring format. The production checklist can feel abstract until a reader sees it pointed at a familiar object: a weekend app with generated screens, Supabase, model calls, and a launch button. That is the most common reader context for this pivot.

The article should not claim that a specific submitted app failed unless that app exists and the owner approved publication. That would be fake experience. The stronger version is a repeatable teardown method. It tells readers what evidence to send, what will be inspected, and how findings will be ranked. When real submissions arrive, future teardowns can use the same rubric without rewriting the rules each time.

The limitation is scope. This teardown does not replace penetration testing, code review, or legal review. It is a first production screen for small AI apps. That is enough value for the launch corpus because it moves the reader from 'my generated app works' to 'my generated app has evidence'.