47 checks, 8 areas, one public URL. That is the entire input we need at Audit Vibe Coding to produce a scored report for an AI-generated project. No repo access. No integration. No SDK. The average vibecoded project we have audited scores 31 out of 100. Production-ready starts at 80.
This post walks through what a single URL actually reveals, what stays hidden without source code, and why the order you fix things in matters more than the number of findings.
What a public URL gives you
A browser pointed at a live app can surface more than most people expect. Here is the breakdown by audit area, based on what we run at Inithouse across our portfolio of products (including Be Recommended and Watching Agents):
| Area | What the URL reveals | What it misses |
|---|---|---|
| Security | Exposed API keys in client bundles, open Supabase anon keys, missing CSP headers, mixed content | Server-side auth logic, database RLS rules |
| SEO | Missing meta tags, broken canonical URLs, no structured data, thin content signals | Server-side redirects, internal linking depth |
| Performance | Unoptimized images, render-blocking scripts, layout shifts, bundle size | Backend query times, database bottlenecks |
| Accessibility | Missing alt text, low contrast ratios, no focus indicators, broken ARIA labels | Screen reader edge cases in dynamic flows |
| Code quality | Unminified bundles, console errors, unused CSS, hydration mismatches | Internal code structure, test coverage |
| Privacy | Missing cookie consent, third-party trackers without disclosure | Server-side data handling, encryption at rest |
| Stability | Console errors on load, broken routes, 404s on linked resources | Error handling under load, edge case crashes |
| UX / Mobile | Tap targets too small, horizontal overflow, missing viewport meta | User journey completion rates, heatmap data |
That is 47 individual checks. Most vibecoded apps fail at least 15 of them on first scan.
The typical findings (and why order matters)
We have now run enough audits to see a pattern. The three most common critical findings, in order of how often they appear:
1. Exposed secrets in the client bundle. Supabase anon keys, Stripe publishable keys mixed with internal tokens, API endpoints hardcoded with auth. This is the first thing we check because it is the easiest to exploit and the fastest to fix. One grep through the JS bundle, one env variable change, done.
2. Zero SEO foundation. No meta description, no Open Graph tags, no sitemap, no robots.txt. The app works, but search engines see a blank wall. For a vibecoded project that just shipped, this means zero organic discovery until someone manually adds what Lovable, Cursor, or Replit did not generate.
3. Accessibility below baseline. Missing form labels, no skip-to-content link, images without alt text. Most AI code generators produce visually correct output that a screen reader cannot parse. This is invisible to the builder but affects roughly 15% of potential users.
The instinct is to fix everything at once. What we recommend instead: fix in severity order, not discovery order. A leaked API key at severity "critical" matters more than a missing favicon at severity "low," even though both showed up in the same scan.
The report scores each finding on two axes: severity (how bad is it if you ignore it) and difficulty (how long does it take to fix). Sorting by severity-descending, difficulty-ascending gives you the highest-impact, lowest-effort fixes first. Three hours of work after receiving the report typically moves a project from a score of 31 to 55 or higher.
What you cannot audit from a URL
Being honest about limits is part of delivering a useful report. A public URL does not let us see:
- Row-level security policies in your database
- Whether your server validates input before writing it
- How your backend handles rate limiting
- What your test coverage looks like
- How the app behaves under 1,000 concurrent users
We flag these as "not assessed" rather than guessing. If a project needs deeper review (source code audit, load testing), we note it explicitly. Building at Inithouse, we learned early that an audit claiming to cover things it cannot verify is worse than one that openly says "we did not check this."
Running it on your own project
The process: paste your URL at auditvibecoding.com, add your email, pick an audit focus (or select all eight areas). Report lands in your inbox within 24 to 48 hours.
We built this because we needed it ourselves. Running a portfolio of 14+ products across Lovable, Cursor, and custom stacks, we kept finding the same issues in our own deploys: exposed keys, missing headers, broken accessibility. Instead of re-running the same manual checklist for each product, we turned it into Audit Vibe Coding.
If your project was built with AI tools and it is live, the question is not whether there are findings. There are. The question is which ones to fix first.
Top comments (0)