Free self-check
Have your own AI run the five-flaw check.
One prompt, pasted into the tool that built your app. It checks the five flaws by name and reports findings the way I do — with a severity count, never a score.
Below it, the rules that stop those five being written in the first place. Free, both of them. They run locally, in your tools, on your repo. No sign-up, nothing sent to me.
Run it
Paste it into your tool.
Claude Code, Cursor, Windsurf, or the chat of whatever built your app. Open your project and run it there.
The prompt
Select it, copy it, and paste it into your project:
You are running the Vibe2Prod five-flaw self-check on this
repository. Read the codebase — read-only, change nothing — and check, by
name:
1. Hardcoded keys — secrets or API keys in source, in client-side env
vars (VITE_, NEXT_PUBLIC_), or in the built bundle. A Supabase
service-role key counts even where row-level rules exist, because it
bypasses every one of them.
2. RLS disabled — database tables reachable without row-level rules,
blanket grants, views that bypass policies. Read each policy's
predicate, not just whether a policy exists: USING (true) is a
policy, and it leaves the table open to anyone.
3. Missing input validation — user input rendered as HTML, trusted
request bodies, unvalidated amounts, URLs or ids.
4. Broken auth logic — routes or endpoints whose only protection is the
UI, identity read from browser storage, admin checks that run after
the data is already fetched.
5. Console and data leakage — secrets or user data logged to the
console, over-wide API responses, source maps in production.
Report every finding in this exact shape:
- What you saw (file and line)
- What it costs the owner if it triggers, in plain business terms
- The fix
- Severity: Critical / High / Medium / Low
End with:
- the severity count ("N findings: X critical, Y high…") — no score,
no ready/not-ready verdict
- a list titled "What this check could not see", naming what a static
read of this repo cannot rule out: live configuration, platform
dashboard settings, dependency behaviour at runtime, anything you
could not open.
Do not soften findings. Do not conclude whether the app is safe to
launch.The output shape is the same one the paid report uses — this check is a working sample of the prompts every audit ships with.
Stop writing them
The cheapest flaw is the one never written.
The check above reads what is already there. These rules go in the file your AI tool reads before it writes anything, so the same five stop arriving in new code. Paste them into whichever of CLAUDE.md, .cursorrules, .windsurfrules or AGENTS.md your project uses.
Adapt the bracketed parts to your stack. The env prefix, the database and the validation library are what change between projects; the principles are not.
What they do is lower the rate at which new flaws get written. They do not remove the ones already in your codebase, and a context file is guidance rather than enforcement: a tool can still ignore it on any given day. Prevention and detection are different jobs, and neither replaces the other.
The rules
Select it, copy it, and paste it into your project’s AI context file:
## Production rules (Vibe2Prod)
### Secrets
- Never place a secret under the client env prefix ([VITE_ /
NEXT_PUBLIC_ / …]) — that prefix compiles it into the bundle every
visitor downloads. Only publishable/anon keys may carry it.
- Service-role, secret and private keys live in server-side env only.
There is no safe way to hold them in browser code.
- Never commit `.env`. If a secret was ever committed or bundled, it is
burned: rotate it before any code fix.
### Data access
- Every new table ships with row-level security enabled and its policies
in the same migration. A table without policies is a bug, not a TODO.
- No `SECURITY DEFINER` functions or owner-privileged views over
protected tables without a stated reason in a comment.
- Access rules live in the database [or platform rules file], never only
in application-side filters.
### Input
- Every route, serverless function and webhook validates its body with a
schema ([the project's validation library]) before acting on it.
- The server derives which records to touch from the session, never from
ids arriving in the request body.
- User-entered text renders escaped by default. No raw-HTML sinks
(`dangerouslySetInnerHTML`, `innerHTML`, `v-html`) for user content.
- Amounts, quantities and rates get bounds and sign checks server-side.
### Auth
- Identity comes from a verified session or token, server-side — never
from localStorage, cookies the client writes, or the request body.
- The permission check runs before the data is fetched, not after.
- Webhooks verify signatures before processing. No unsigned money.
- Roles are data with controlled writes: no admin-by-email-pattern, no
role columns writable by the user's own update calls.
### Leakage
- No `console.log` of tokens, sessions or user records in production
paths.
- API responses enumerate their fields. Never return whole rows and let
the client choose what to show.
- Errors shown to users are generic; stack traces stay server-side.
- Production builds ship no source maps.
### Verification
- Every security-relevant change ends with a stated check that proves it
took ("After applying, check: …") — and the check is actually run.
Reporting success without running the check is a failure.The limits
What it cannot do.
It is the author of the code, marking its own work: the flaw a tool wrote is the flaw it is least likely to flag. It reads what it can open, and it cannot weigh what a finding costs your business.
The audit closes that gap with a method that did not write your code, and a person who weighs what each finding costs you before signing it.
€350 + VAT · 48 hours
The audit does it properly.
Seven domains, every finding with evidence and business consequence, and the “what I could not see” list a self-check cannot honestly write.
€430.50 including VAT.