What does a Bolt app audit check?
Prototype-to-production gap
The defaults that were fine for a demo and are not fine for customers.
Database rules
Row-level security and tenant isolation on every table the client can reach.
Exposed keys
API keys and tokens in the client bundle, the repo, or a deployed environment variable.
Server-side authorization
Access checks that survive someone calling the API without your frontend.
Auth flows
Session handling, reset paths, and the confirmation steps often left in a default state.
Input validation
Server-side validation on every write, not just client-side form checks.
Deployment configuration
Build settings, environment separation, redirects, and function permissions.
Integrations
Payment, email, and storage wiring, including webhook signature verification.
Dependencies
Generated package set, known CVEs, and unused weight in the bundle.
Error handling
Failure states a user actually sees, and errors currently swallowed in the console.
Performance
Bundle size, render behaviour, and query patterns under real data volume.
Scalability
Where the generated architecture stops holding, and what changes first.
Observability
Error tracking and logging sufficient to debug a production incident.
Backups
Whether data can be restored, and whether that has been tested once.
Maintainability
Structure, duplication, and how much of the code no human has read.
Other audits
Each audit answers a different question. Most engagements combine two or three.
Build with
confidence.
AI builds the product. Vibecop makes sure it won’t break in production, fail under scale, or expose your users to risk. One audit. Fewer expensive surprises.