Why Inithouse built Audit Vibe Coding: an audit for AI-generated projects that needs nothing but a URL
We run 47 checks across 8 areas on every project that comes through Audit Vibe Coding. The average vibecoded project scores 31 out of 100. Production-ready starts at 80. That gap is why we built it.
At Inithouse we ship a growing portfolio of products, most of them built with AI tools. Lovable, Bolt, Cursor, v0. Shipping fast is the point. But shipping fast without knowing what broke is how you end up with a public-facing app that leaks user data through exposed API keys, has zero meta tags for search engines, and loads in 9 seconds on mobile.
We learned this the hard way.
The problem we kept running into
Early on, when a product was ready to go live, someone on the team would do an ad-hoc review. Open DevTools, poke around, check a few things. It was inconsistent. One person would catch a missing Content-Security-Policy header. Another would notice the Lighthouse score was 38. Nobody checked both every time.
We tried writing a checklist. It grew to 40+ items. Nobody wanted to run through it manually for each deploy. And every time we added a new product to the portfolio (we now have over a dozen live), the same problems kept reappearing. The checklist itself was the product trying to be born. We just didn't see it yet.
V1 failed, and here's why
The first version of Audit Vibe Coding asked for repository access. We wanted to scan the actual codebase: look at dependencies, check for hardcoded secrets, trace data flows.
It failed for two reasons.
First, most users don't have clean repos. Vibecoded projects are built iteratively in tools like Lovable, and the git history is a series of AI-generated commits. Diffing that is noise, not signal.
Second, access friction killed conversion. Asking someone to connect their GitHub or paste a deploy key meant they had to trust us with their codebase before seeing any value. Most people bounced at that step.
The root cause: we were thinking like traditional code auditors. But vibecoded projects aren't traditional codebases. They're running apps. The artifact that matters is the deployed output, not the source tree.
The URL-only decision
We rebuilt around one input: a URL. Give us the address of your running app, and we audit what your users actually experience.
This changed our conversion and our coverage model:
- No repo access means no trust barrier. You don't share source code with us.
- No SDK, no integration, no agent to install. Just a URL.
- We test the production artifact, which is what actually matters for security, performance, and SEO.
- Delivery in 24-48 hours, because the scope is defined by what's reachable from the URL.
The tradeoff is real. We can't catch every buried dependency or unused code path. But we cover what hits users and what search engines see, which for most vibecoded products is the entire attack surface anyway.
What the 47 checks cover
We organized the audit into 8 areas. Each area gets a score, and the scores roll up into a single number out of 100.
Security - Exposed API keys, CSP headers, auth flows, data leaks. Common finding: Supabase anon key visible in client bundle with no RLS policies.
Privacy - Cookie consent, data collection disclosure, third-party trackers. Common finding: analytics firing before consent banner interaction.
Performance - Core Web Vitals, bundle size, image optimization, caching. Common finding: 4 MB uncompressed hero images, LCP north of 6 seconds.
SEO - Meta tags, structured data, crawlability, indexation signals. Common finding: missing canonical tags causing duplicate content across routes.
GEO/AEO - AI engine discoverability, entity signals, citation readiness. Common finding: no structured FAQ data for AI answer retrieval.
Accessibility - WCAG compliance, keyboard navigation, screen reader support. Common finding: form inputs without labels, contrast ratios below 3:1.
UX Flows - Core user journeys, error handling, empty states. Common finding: checkout or onboarding flows that break silently on misconfigured third-party keys.
Mobile UX - Responsive behavior, touch targets, viewport handling. Common finding: navigation menus unreachable on screens below 375px.
Every finding comes with a severity rating (critical, high, medium, low) and a difficulty estimate (quick fix, moderate, significant), so teams know where to start.
What the numbers tell us
After running audits across dozens of vibecoded projects, patterns emerged.
The average score is 31. Not because the builders are bad. AI code generators optimize for "it works" and skip the production hardening that separates a demo from a product people trust with their data.
The most common critical issues are security-related: exposed environment variables, missing rate limiting, absent input validation. These are things AI tools simply don't generate by default.
Performance is the second weakest area. AI tools tend to ship unoptimized images, bloated bundles, and zero caching headers. The gap between "works in preview" and "loads fast in production" is wide.
The pattern we see most: a team ships something with Lovable or Bolt, gets early users, then hits a wall when performance or security complaints start coming in. By then they've already moved on to the next feature. The audit catches these problems before users do.
Most projects can go from 31 to 60+ with a focused sprint on the critical and high-severity findings. Getting to 80+ usually requires a second pass after the quick wins are deployed.
Where this sits now
Audit Vibe Coding is live and taking orders. No account needed. Submit a URL, get a scored report with prioritized fixes within 48 hours, money-back guarantee.
We built this because we needed it for our own portfolio. Every product at Inithouse goes through this audit before we call it production-ready. If you're shipping with AI tools and want to know what's broken before your users find it, that's the use case.
The vibecoding space is growing. The quality tooling hasn't caught up. We're working on closing that gap.
The concern about AI code generators primarily focusing on functionality rather than reliability is a valid one. In my experience, shipping products that involve AI means balancing quick iterations with solid engineering practices. When we first explored automation in our writing processes, we had to ensure that the generated content didn’t just meet a basic quality threshold, but also aligned with our SEO standards and maintained user trust.
For instance, early on, we encountered situations where generated content pieces lacked the depth or coherence needed for serious engagement. To tackle this, we implemented a two-step approach: first, we used the AI for initial drafts, and then we brought in human editors for final reviews. This not only enhanced the quality but also kept our users confident that the content was trustworthy.
One practical lesson from that phase was benchmarking. We set performance metrics around engagement rates post-publication. For example, we noticed that articles edited by humans versus those left unreviewed had a difference in average reading time—about 40% higher for those that went through our editorial process. This reinforced the value of human oversight in maintaining quality.
Ultimately, the optimization challenge isn't just about leveraging AI but ensuring that the final outputs are polished and trustworthy. It can be tempting to lean solely on tech solutions, but a blended approach often provides the best results. It’s a complex dance of speed versus reliability, and finding the right balance is key to building something that not only works but is also trusted.
The “deployed output is the artifact that matters” point is exactly what caught my attention.
There’s a similar problem emerging with AI agents: teams can inspect configuration, prompts and controls all day, but once the system is live the more important question becomes what did it actually do?
I’m building OpsWatch around that gap — independently testing observed agent behaviour, escalation, evidence and failure paths against the expected outcome rather than assuming the implementation proves itself.
Have you thought about extending your audit model from the application surface into autonomous workflows where the system is making or triggering real decisions?