The standard
What I check, and what I refuse to claim.
The domains I read, the flaws I name, the point where the scope stops, and how your code is handled while I have it. When the audit says it runs against a published method, this page is the method. It does not bend to fit a client.
What I examine
The seven domains.
From the repository or platform, and from the running application observed as an ordinary user.
| Domain | What that means here |
|---|---|
| Data exposure | whether user data is reachable without authorisation: storage/RLS rules, unauthenticated API routes, keys shipped to the client |
| Identity and authorisation | how auth is actually built; the exposed surface; auth UI with no backend enforcement |
| Code, dependencies, supply chain | secrets committed to the repository; versions frozen at generation time; packages whose provenance the repository cannot establish. Published advisories are checked by hand during review, because the automated pass makes no network request |
| Architecture and ownership | what the system is made of, what depends on what, what the owner cannot explain |
| Infrastructure and deploy | environment configuration, deploy path, rollback capability |
| Observability | what code and configuration say about whether you would find out something broke |
| AI change governance | how AI-generated change enters the codebase and what reviews it |
The five flaws
Every report names the same five.
AI-built apps tend to fail in the same five ways. Every report names which of the five appeared, in the same vocabulary.
Hardcoded keys
secrets written into code or shipped to the client, usable by anyone who looks
RLS disabled
database rules that let any user reach other users’ data
Missing input validation
the app believes whatever it is told, so a form field becomes a way in
Broken auth logic
login screens the backend never enforces — auth UI without auth
Console and data leakage
debug output and over-generous responses handing user data to the browser
All five appear in the InvoicePilot specimen: a codebase I broke on purpose and audited in public, with each flaw named at the finding that carries it.
The line I hold
Findings, never a verdict.
The audit reads your code and configuration. It reports findings: ranked, evidenced, with fixes. It does not issue a readiness score, a green light, or a ready/not-ready call.
The limits are part of the method: nothing is exploited, no load is generated, no production data is touched, and the scope is not a penetration test, a certification or a compliance opinion. No audit is exhaustive; where this one could not see, the report says so by name.
The automated pass makes no network request either — not to your app, your platform, a package registry or a vulnerability database. Where something was looked up, a person looked it up, and the report attributes it to a person.
A number that answers “can I launch?” is a verdict, and a verdict requires testing the system and understanding the business. That deeper work is the Production Readiness Review — the only place a verdict comes from.
A list you can act on beats a number that feels like permission.
How your code is handled
What I promise about your code.
- Access is read-only and used for nothing else.
- Code and credentials are deleted after delivery.
- Anonymised finding statistics are retained only with written permission — the permission line lives in the authorisation form, not in fine print.
- NDA available on request.
- No trackers on this site beyond privacy-friendly analytics. No sponsored anything.
Hold me to it
Hold me to this.
Five questions, a fit check, a fixed price — and a report that follows exactly what this page promises.