BUILD OS · PROBLEM GRAPH
Problems you can diagnose and verify.
Each page starts with a direct answer, explains the failure mechanism and shows how to prove a fix. Internal evidence is linked to its source and labelled as documented.
Billing
Stripe payment succeeded, but the user is still locked out
The payment redirect and the application’s access state have likely diverged. Treat the signed server-side payment event as the source for durable entitlements, then check that the event was verified, processed and attached to the correct customer or account.
Diagnosis and verification →Authorization
Supabase users can access other users’ data
Authentication proves which user made a request; it does not prove that the user owns the requested row. Check row level security and every server-side read and write with two separate accounts, including requests that substitute another user’s record ID.
Diagnosis and verification →Production readiness
An AI-built app works, but is it ready for production?
A working demo proves that one path ran once; it does not prove that access control, payment state, failure recovery, backups or production visibility work. Choose the checks that apply to the product and verify them in staging or a production-like environment before inviting real users.
Diagnosis and verification →Authentication
Supabase magic link email is not received
Check the email provider logs first: if no send was requested, the app or a rate limit stopped it; if it was sent but filtered, the sending domain is not authenticated; if it arrives but fails, the redirect URL is not allowed or the one-time link was already consumed. Production needs a real SMTP provider on a verified domain.
Diagnosis and verification →Authorization
Supabase returns “permission denied” or an empty list after enabling RLS
Row level security denies by default: with RLS on and no policy allowing that operation for that role, Postgres refuses the query (or returns zero rows for SELECT). Write one owner-scoped policy per operation, add WITH CHECK for inserts and updates, and make sure the request carries the user’s session. Never fix it by disabling RLS.
Diagnosis and verification →Deployment
Environment variable is undefined on Vercel but works locally
The value exists in your local .env file but not in the deployed environment that ran the code — or it was added after the last deployment, or browser code reads a variable without the NEXT_PUBLIC_ prefix. Define it per environment (Preview and Production), redeploy, and keep secrets server-only.
Diagnosis and verification →
Pages are added when there is enough specific explanation and provenance to be useful; this index is not generated from keyword variations.