This is an example report for a fictional app, showing exactly what you get: an overall score, category breakdown, and evidence-backed issues with copy-paste fix prompts.
Launch readiness
Acme Notes (demo)
Launch readiness 58/100 — not launch-ready yet. Found 8 issues across the checked categories, including a production-hardening checklist. 1 critical issue puts user data or trust at direct risk.
Category scores
Issues (8)
User B can open User A’s project URL
Logged in as User B, opening User A's private project URL (/projects/42) returned a 200 page without an access-denied redirect.
If User B sees User A's data, that's a critical broken-access-control (IDOR) bug — the #1 way vibe-coded apps leak customer data.
Scope every query to the authenticated user's id and enforce it with row-level security / ownership checks, not just the URL.
My app uses Supabase. Fix broken access control on /projects/[id]. Ensure Row Level Security is enabled on the projects table and the SELECT policy is `user_id = auth.uid()`. Never rely on the client to hide data. Verify with a second test user that they cannot read the first user's rows.
Dashboard remains visible after logout via browser back
After logging out, pressing the browser back button re-rendered the dashboard with cached private content before any redirect.
On shared or public computers, the next person can read the previous user's data.
Set no-store cache headers on authenticated pages and re-check the session on the server for every private route.
In my app, prevent authenticated pages from being restored after logout. Add `Cache-Control: no-store` to private routes and verify the session server-side on every request so the back button can't show cached private data.
No privacy policy linked despite collecting user data
No link or footer text mentioning a privacy policy was found on the homepage.
If you collect any user data, a privacy policy is expected by users, app stores, ad networks, and (in many regions) the law.
Add a Privacy Policy page and link it in the footer.
Add a Privacy Policy page to my app and link it in the footer. Cover what data is collected, why, how it's stored, and how users can request deletion. Keep it plain-English.
Homepage headline is too generic and doesn’t say who it’s for
The hero uses 'AI-powered' and 'seamless' but never names a specific target user or the problem solved.
When visitors can't self-identify in the first sentence, they assume it's not for them and leave.
Rewrite the hero to name the exact target user, the painful problem, and the concrete result.
Rewrite my hero section. Name the exact target user, the painful problem, and the specific result. Cut buzzwords like 'AI-powered' and 'seamless'. Replace generic feature cards with outcome-based sections and add a real product screenshot.
Open Graph image missing — social shares look unfinished
Missing: og:image, og:url.
Without Open Graph tags, links shared on X, LinkedIn, Slack, and Discord render as bare URLs with no preview — a big trust and CTR hit at launch.
Add og:title, og:description, og:image (1200×630), and og:url, plus twitter:card tags.
Add complete Open Graph and Twitter card meta tags to my site, including a 1200×630 og:image, og:title, og:description, and og:url. Generate the share image if one doesn't exist.
Confirm authorization: roles & permissions enforced server-side
Can't be verified from outside a running URL — confirm this is in place. (Part of the production-hardening checklist.)
Checking permissions only in the UI lets any user call the API directly and act as an admin. This is the #1 vibe-coded vulnerability.
Enforce role/permission checks on the server for every mutating and sensitive-read endpoint. Never trust client-side role flags.
Audit my app's API routes and enforce authorization server-side: every mutating or sensitive-read endpoint must verify the authenticated user's role/permission before acting. Don't rely on hiding buttons in the UI. Show me each endpoint and the check you added.
Confirm session management & token expiry
Can't be verified from outside a running URL — confirm this is in place. (Part of the production-hardening checklist.)
Long-lived or non-expiring tokens mean a stolen token works forever, and missing logout invalidation leaves sessions alive.
Use short-lived access tokens with refresh rotation, expire sessions, invalidate tokens on logout/password change, and store tokens in HttpOnly cookies.
Review my auth/session handling: set short-lived access tokens with refresh rotation, expire idle sessions, invalidate tokens on logout and password change, and store tokens in HttpOnly, Secure, SameSite cookies.
No obvious rate limiting on the AI generation endpoint
Three low-volume requests to /api/generate returned no 429 and no rate-limit headers. Not proof none exists, but none was observed.
Unthrottled expensive endpoints can be abused to run up your AI bill or degrade the service.
Add rate limiting and per-user quotas — e.g. middleware rate limiting, Upstash Redis, or Cloudflare rate limiting.
Add rate limiting to my /api/generate endpoint: per-user and per-IP limits with a sensible window, return 429 with a Retry-After header when exceeded. Suggest an Upstash Redis-based approach for serverless.
Get this for your app
Submit your app for a free mini-scan: overall score plus your top 3 production-readiness issues.
Join the waitlistLaunchGuard checks common launch-readiness risks and obvious production issues. It is not a replacement for a full professional security audit, legal review, or accessibility certification.