Launch status
Safe to share privately with test users. Not safe for paid customers or production customer data.
Sample deliverable
What we found in 90 minutes on a Lovable-built B2B SaaS.
This anonymized report shows the level of specificity a founder should expect from a production readiness review: evidence, severity, fix path, and what must be checked before real customer data enters the app.
Executive verdict
The app looked demo-ready but not production-ready. The core workflow rendered, but customer data, billing, and admin surfaces needed hardening before launch.
Main risk
Client-side access patterns made it unclear whether tenants could read or mutate data outside their account.
Fastest path
Rotate keys, lock route auth, prove RLS policies with tests, and move payment-sensitive actions behind server code.
Findings
Specific issues, severity, evidence, and recommended fixes from the sample review.
High: Supabase service access pattern
Evidence: Public JavaScript referenced Supabase project config and performed direct table reads from the browser.
Fix: Confirm no service-role key is present, rotate all keys, enforce RLS on every table, and add tenant-isolation tests for anonymous, authenticated, and cross-account users.
High: Admin route rendered publicly
Evidence: /admin returned a 200 response and loaded dashboard chrome before redirecting on some client states.
Fix: Move auth and role checks into server middleware or route loaders. Never rely on hidden links or client-side redirects for admin protection.
High: Stripe workflow trusted client state
Evidence: Checkout state was assembled in browser code and did not show a server-side price or tenant verification step.
Fix: Create checkout sessions server-side, verify tenant ownership before session creation, and validate webhook events before changing account state.
Medium: Missing security headers
Evidence: The production domain did not return Content-Security-Policy, HSTS, or Referrer-Policy headers.
Fix: Add hosting-level headers, start with report-only CSP if needed, and verify third-party scripts before enforcement.
Medium: No rollback plan
Evidence: Schema changes were applied manually in Supabase with no migration history in the repo.
Fix: Move schema changes into migrations, require review before production changes, and document rollback for destructive operations.
Low: Observability gap
Evidence: Failed API calls appeared in the browser console, but no error tracking or alerting target was configured.
Fix: Add error monitoring, uptime checks, and a lightweight incident checklist before launching paid users.
Recommended 72-hour fix plan
The goal is not a rewrite. The goal is to remove launch blockers in the smallest safe order.
- Day 1: rotate exposed or uncertain keys, remove public source maps, add server-side admin route protection.
- Day 1: add security headers and verify CORS is restricted to intended origins.
- Day 2: write RLS policies for every customer-owned table and test cross-tenant reads and writes.
- Day 2: move Stripe session creation and webhook state changes behind verified server code.
- Day 3: add migrations, rollback notes, error monitoring, and a launch checklist for the first customer cohort.
The useful deliverable is not a generic score. It is the shortest concrete path from working demo to production-safe app.