Lovable Post-Launch Checklist

Choose the checks for the actual stack

• Supabase launch checks for this backend

Confirm the environment before creating records

Lovable documents shared backend data between preview and the published app. Its browser-testing docs also mention test/live environments for some Cloud apps. Confirm which environment your project uses; do not treat the preview label as proof of an isolated database. Use clearly named records and remove only those test records when finished.

• Lovable: preview and published data
• Lovable: test/live browser-testing scope

Prepare separate identities

Use ordinary users A and B in separate browser profiles or different browsers, plus a clean signed-out profile. Private windows in one browser can share a session, so confirm the active identity before each check. Neither test user should be an administrator or a member of the other's private workspace. As A create TEST-A private; as B create TEST-B private. Save their supported detail URLs, if the app has them. Shared notes need a separate membership contract.

Run the visible positive and negative controls

First confirm both users can create and read their own notes after a reload. Then check each list and the other user's detail URL. A login redirect, not-found page or empty result is acceptable for a denied read, provided no private content appears. If owners cannot read their own records, the feature is broken. Passing these controls establishes only the tested UI behavior.

Optional advanced check: inspect the response

A screen can hide data that still reaches the browser. In Developer Tools, open Network, reload the list or detail page and identify the request that fetches the note. Repeat the supported read as its owner, the other user and the signed-out visitor. The owner response must include the expected note; denied reads must contain no private fields from it. HTTP 200 alone is not a pass. Redact tokens and personal data from saved evidence. If you cannot identify the response, mark this check NOT TESTED rather than assuming the UI proves it.

Use native testing with its documented scope

Lovable browser testing runs against the project preview and can read network requests. Signed-in automation requires Cloud; external Supabase or another auth provider is limited to public pages. On Cloud, an owner or admin can request testing as a specific app user, with approval. Record which identity, environment and response evidence it inspected, then verify the published URL separately.

• Lovable: browser testing and login limits

Check sign-in on the published domain

Lovable Cloud updates auth URLs on publish and adds connected custom domains to allowed redirects. A Site URL you set yourself is preserved. With an external Supabase project, update that project's auth URLs yourself. Your own Google OAuth credentials also require the new domain's redirect URI in Google Cloud Console. If sign-in works only in preview, inspect these settings.

• Lovable: Site URL and redirect URLs

Record, repair and clean up

Record the URL, revision, backend/environment, route, active identity, expected result, observed result and redacted evidence. Keep UI results and response inspection separate: VERIFIED, FAILED or NOT TESTED. Repair a confirmed mismatch with the access contract and repeat the controls on the affected environment. Remove the disposable notes and accounts you created. The result applies only to the recorded flow and version.

Lovable post-launch checklist: repeat after each change

Our recommendation: repeat after an applied schema, access-rule or auth change in the affected environment. Applied database changes can affect a shared backend before new app code is published; a draft proposal is not an applied change. Recheck the published URL after publishing code that reads or writes those records.

If sharing or teams are added, rewrite who should see each record before repeating the test. Lovable recommends reviewing access rules after auth or database-structure changes. This repeat procedure is our practical inference, not a customer outcome or a security guarantee.

• Lovable: database edits and draft acceptance
• Lovable: access review after changes

When a Lovable post-launch check fails: choose one next action

Use the failed check to choose the next change. Keep the published URL, tested identity and redacted evidence with it. This is a troubleshooting procedure, not an observed customer result.

• Published-domain login diagnosis
• Supabase public-key and private-data checks

Copy a focused regression-test request

Replace the placeholders with one feature you can safely test. In Lovable, use native browser testing within its documented preview and sign-in limits. For a synced local repo, give the request to your coding agent and record checks it cannot perform. Do not include real secrets or customer records.

Check one flow: [create and reopen a private note].
URL and revision: [the exact environment and version].
Expected: A can save and reload their note; B and a signed-out visitor cannot read it.
Use only disposable test records and ordinary accounts I authorize. Confirm whether preview and live share the backend before creating records.
For each step report PASSED, FAILED or NOT TESTED, with identity, URL, expected result, observed result and redacted evidence. A hidden screen is not proof that the response withheld data.
For a failure, explain the cause and propose the smallest relevant change. Ask before provider changes or applying migrations. Do not deploy automatically. Repeat the same checks after a reviewed fix.