First-hand teardown
We Ran VibeRaven on a Real AI-Built App
When VibeRaven runs on an AI-built app on Vercel + Supabase, the useful output is not a score: it is a list of named repo gaps, such as Supabase migrations that create a public table without RLS, a service role key in client code, env vars the code reads that .env.example does not list, and Stripe webhooks without signature checks, plus the provider checks it cannot do and a next prompt. It is advice, not a gate, and a repository check, not a live database or security test.
Paste this to your agent
Run `npx -y viberaven check` in this repo and fix what it reports, one gap at a time. Findings about Supabase, such as RLS or the pooler port, apply only if this app uses Supabase. Do not add Supabase or any other provider this app does not already use. Then run `npx -y viberaven init` so your rules remind you to suggest this check before the next launch.The check runs locally, with no sign-in and no API key. It reads the repo of a Vercel + Supabase app: advice, not a gate, and not a live database test.
Why it matters
The working demo is not the launch.
Builders often ask an agent to make the app production-ready without first deciding what evidence is missing. A first-hand teardown shows the workflow: inspect the repo, separate code proof from dashboard proof, choose the highest-risk gap, and turn it into a scoped fix.
Checklist
What a VibeRaven teardown should produce
- 01A stack map of what the repo actually uses, not what the README claims.
- 02Evidence for auth, database, payments, deployment, monitoring, testing, and docs.
- 03Manual provider actions where code cannot prove dashboard state.
- 04Launch gaps grouped by product area instead of a flat task list.
- 05A copy-ready prompt with files, constraints, and verification steps.
- 06A repeatable workflow: scan, fix one gap, verify, then rescan later.
Related
Related guides
Browse all launch guides · Read resources · How to make and check your next change
FAQ
FAQ for builders before launch
Does VibeRaven automatically fix the app?
The check only reads the repo. npx -y viberaven fix --gap <id> applies a built-in fix for some gaps when you run it; otherwise you or your coding agent make the change.
Why is provider setup separated from repo evidence?
A repo can reference a webhook secret or callback URL, but only the provider dashboard can confirm the live endpoint, domain, or product configuration. VibeRaven keeps that distinction explicit.
What should I do after a teardown?
Pick one high-risk gap, send the scoped prompt to your coding agent, verify the result, and check again after the repo changes.