# Vibe-Coded App Pre-Launch Safety Review

Turn a description of a rapidly built app into a prioritized pre-launch safety checklist covering access, data, forms, uploads, integrations, and admin controls.

## Prompt

Act as a defensive pre-launch reviewer for a vibe-coded web or mobile application. Work only from the information provided, distinguish confirmed issues from items that need testing, and never claim that the app is secure or compliant.

App purpose and users:
{{app_purpose_and_users}}

Screens, roles, data, and workflows:
{{screens_roles_data_and_workflows}}

Technical stack and integrations:
{{stack_and_integrations}}

Review the app using this structure:

1. System map: summarize public pages, authenticated areas, roles, admin functions, data stores, uploads, APIs, automations, payments, and third-party services.
2. Sensitive assets: identify user data, private content, credentials, payment information, admin actions, intellectual property, logs, and business-critical records.
3. Priority risks: assess authentication, authorization, row or tenant isolation, public forms, input validation, file uploads, secrets, API exposure, error messages, rate limits, spam and abuse, deletion, backups, logging, and automated actions.
4. Evidence status: label each finding Confirmed from description, Likely risk, or Must test. Never present an untested assumption as a discovered vulnerability.
5. Role and access checklist: define tests for anonymous users, normal users, moderators, admins, and service accounts. Include attempts to read, create, edit, or delete another user's data.
6. Launch blockers: list issues that should stop public launch, issues that can be fixed during a private beta, and lower-priority hardening.
7. Test plan: provide concrete manual tests using test accounts and synthetic data. Do not request real credentials, production user data, or destructive testing.
8. Safer launch plan: propose staged rollout, monitoring, incident contact, rollback, backup, and human-review steps.

Rules: Never ask for API keys, tokens, passwords, service-role keys, private certificates, or real customer records. Recommend qualified technical review for apps involving payments, children, health, legal services, high-value accounts, or sensitive personal data.

## Best for

Founders and non-security specialists preparing a Lovable, Bolt, Replit, Cursor, Codex, or AI-assisted app for private beta or public launch.

## Compatible tools

- Claude
- ChatGPT

## How to use

- Provide an app map with roles, screens, tables, storage, integrations, and automated actions, using placeholders instead of secrets.
- Run the generated tests in a development or staging environment with synthetic accounts and records.
- Treat every launch blocker as unresolved until someone verifies the implementation directly.
- Repeat the review after major authentication, database, upload, payment, or automation changes.

## Customization tips

- Include database policy summaries and route-protection behavior for a stronger authorization review.
- Ask for the checklist grouped by frontend, backend, database, storage, and operations.
- Add your planned beta size and risk tolerance to get a staged rollout plan.

## Example input

App: a community library where visitors browse resources, registered users comment and rate, and admins upload files and publish content. Stack: React and Supabase. Data: profiles, comments, ratings, requests, admin notes, and private storage files.

## Example output

Launch blockers to verify: confirm row-level policies prevent users from editing other profiles or comments; confirm only admins can publish resources and generate private-file access; ensure service-role credentials are never shipped to the browser; validate and rate-limit public comments and requests; test private storage URLs and replacement cleanup. Use anonymous, normal-user, and admin test accounts and record expected versus actual access for each table and route.