1. Backend ownership
Identify whether production, preview, and local builds use Lovable Cloud, the owned Supabase project, or a mixed state.
A migration can look finished after schema, data, and auth users move over, then still fail at launch because the frontend points at the wrong backend, generated migrations depend on dashboard defaults, Storage overwrite policies are incomplete, or role-matrix tests were skipped.
The brittle part is proving the rebuilt app behaves the same when Lovable Cloud is no longer the backend boundary.
Identify whether production, preview, and local builds use Lovable Cloud, the owned Supabase project, or a mixed state.
Record first-login evidence, profile foreign-key behavior, session refresh behavior, and fallback if transferred accounts fail.
Run a disposable rebuild or local reset so missing grants, broken policies, and generated revokes surface before launch.
Check bucket names, object-path ownership, public URL rewrites, and overwrite behavior for avatar or profile-image flows.
Test no-session, anon, authenticated owner, wrong owner, and service-path behavior without broad make-it-work grants.
Verify deployed environment variables, old URL removal, rollback plan, and smoke tests after pointing the frontend at the new backend.
These pages do not connect to Supabase and do not need secrets. The paid path stays behind the scoped checkout page after the fixed scope is clear.