Sample report

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.

58/ 100

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.

1 Critical4 High3 Medium

Category scores

Production Safety42
Security & Auth40
Accessibility & UX66
Trust & Legal51
Launch Setup63
Vibe-Code Polish48

Issues (8)

CriticalSecurity & Auth
Open

User B can open User A’s project URL

Confidence: LikelyNeeds user confirmation
Evidence

Logged in as User B, opening User A's private project URL (/projects/42) returned a 200 page without an access-denied redirect.

Why it matters

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.

Suggested fix

Scope every query to the authenticated user's id and enforce it with row-level security / ownership checks, not just the URL.

Exact fix prompt
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.
HighSecurity & Auth
Open

Dashboard remains visible after logout via browser back

Confidence: ConfirmedVerified
Evidence

After logging out, pressing the browser back button re-rendered the dashboard with cached private content before any redirect.

Why it matters

On shared or public computers, the next person can read the previous user's data.

Suggested fix

Set no-store cache headers on authenticated pages and re-check the session on the server for every private route.

Exact fix prompt
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.
HighTrust & Legal
Open

No privacy policy linked despite collecting user data

Confidence: LikelyFailed
Evidence

No link or footer text mentioning a privacy policy was found on the homepage.

Why it matters

If you collect any user data, a privacy policy is expected by users, app stores, ad networks, and (in many regions) the law.

Suggested fix

Add a Privacy Policy page and link it in the footer.

Exact fix prompt
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.
MediumVibe-Code Polish
Open

Homepage headline is too generic and doesn’t say who it’s for

Confidence: LikelyNeeds user confirmation
Evidence

The hero uses 'AI-powered' and 'seamless' but never names a specific target user or the problem solved.

Why it matters

When visitors can't self-identify in the first sentence, they assume it's not for them and leave.

Suggested fix

Rewrite the hero to name the exact target user, the painful problem, and the concrete result.

Exact fix prompt
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.
MediumLaunch Setup
Open

Open Graph image missing — social shares look unfinished

Confidence: ConfirmedVerified
Evidence

Missing: og:image, og:url.

Why it matters

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.

Suggested fix

Add og:title, og:description, og:image (1200×630), and og:url, plus twitter:card tags.

Exact fix prompt
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.
HighSecurity & Auth
Open

Confirm authorization: roles & permissions enforced server-side

Confidence: Needs ReviewNeeds user confirmation
Evidence

Can't be verified from outside a running URL — confirm this is in place. (Part of the production-hardening checklist.)

Why it matters

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.

Suggested fix

Enforce role/permission checks on the server for every mutating and sensitive-read endpoint. Never trust client-side role flags.

Exact fix prompt
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.
HighSecurity & Auth
Open

Confirm session management & token expiry

Confidence: Needs ReviewNeeds user confirmation
Evidence

Can't be verified from outside a running URL — confirm this is in place. (Part of the production-hardening checklist.)

Why it matters

Long-lived or non-expiring tokens mean a stolen token works forever, and missing logout invalidation leaves sessions alive.

Suggested fix

Use short-lived access tokens with refresh rotation, expire sessions, invalidate tokens on logout/password change, and store tokens in HttpOnly cookies.

Exact fix prompt
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.
MediumProduction Safety
Open

No obvious rate limiting on the AI generation endpoint

Confidence: Needs ReviewNeeds user confirmation
Evidence

Three low-volume requests to /api/generate returned no 429 and no rate-limit headers. Not proof none exists, but none was observed.

Why it matters

Unthrottled expensive endpoints can be abused to run up your AI bill or degrade the service.

Suggested fix

Add rate limiting and per-user quotas — e.g. middleware rate limiting, Upstash Redis, or Cloudflare rate limiting.

Exact fix prompt
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 waitlist

LaunchGuard 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.