# A practical pre-publish check for a Lovable app

*Independent, documentation-based checklist. This is not a penetration test, certification, or a claim that a particular Lovable project was tested. Reviewed 1 October 2026.*

A polished preview can still hide a broken checkout, a public database rule, or a secret in browser code. Use this short pass before sharing a prototype with real users. It combines Lovable's own preview, testing, and security guidance with practical checks a builder can do without treating a green scan as a guarantee.

## 1. Write down what “works” means

Pick one important user journey and make its expected result concrete. For a booking app, for example: “A signed-in user can create one booking for an available slot; a second user cannot read or edit it; a signed-out visitor sees only public information.” Include the failure case too: what should happen for invalid input, no results, a network error, or an expired session?

Build and review one complete slice at a time. Keep the requirements in the project’s Knowledge or another project note so follow-up prompts have the same product context.

## 2. Walk the app as a visitor

In Preview, click every primary button and complete the main flow from start to finish. Check desktop and phone layouts. Try empty, invalid, loading, success, and error states. Then test the published URL: it is a snapshot, so it may not match the latest preview until you publish again.

If a flow uses accounts or payments, test both a signed-out visitor and the expected user roles. A successful screen is not proof that the server enforces the same permissions.

## 3. Check data rules at the database boundary

List the tables and decide which records are public, user-owned, or admin-only. For each private table, inspect the actual row-level security policies and verify both reads and writes for:

- a signed-out visitor;
- the record owner;
- a different signed-in user; and
- an administrator, if the app has one.

“RLS is enabled” is only a starting point. A permissive policy can still expose every row. Also check storage buckets and server functions that can perform privileged actions.

## 4. Keep secrets out of the browser

Anything shipped to the browser can be inspected. Search the client bundle and repository for private API keys, service-role tokens, and credentials. Keep secrets in the platform’s secret store and make privileged calls server-side; validate authorization and inputs on the server, not only in the UI.

## 5. Run the scans, then read the findings

Run Lovable’s Quick scan and Deep scan after meaningful changes and before publishing. Review the evidence behind each finding, fix critical issues, and rerun the scans so the results match the version you intend to ship. The automated checks can help catch common problems, but Lovable explicitly says they do not guarantee complete security or replace a thorough review.

## 6. Publish deliberately

Confirm the live URL shows the version you reviewed. Repeat the main user journey on the published app, inspect role boundaries once more, and check logs for failed requests. Keep the last known-good version available so a broken release can be reverted quickly.

### A useful review prompt

> Before changing code, map the app’s routes, tables, storage buckets, edge functions, and external API calls. For each data operation, state who should be allowed to read or change it and identify the server-side rule that enforces that. Flag any secret in browser-visible code. Then propose a small verification plan for signed-out, owner, and other-user cases. Do not claim the app is secure just because a scan passes.

### Official references

- [Lovable security overview](https://docs.lovable.dev/features/security)
- [Security best practices for Lovable apps](https://docs.lovable.dev/tips-tricks/security-best-practices)
- [Preview and test your app](https://docs.lovable.dev/features/projects/preview)
- [Test and verify your app](https://docs.lovable.dev/features/testing)
- [Project version history](https://docs.lovable.dev/features/projects/history)

This guide is an independent workflow aid, not affiliated with or endorsed by Lovable. For sensitive data, payments, or safety-critical use, obtain a qualified review appropriate to the application.