At Inithouse, we ship AI-generated products. A lot of them. Our portfolio includes apps for couples games, tarot readings, AI song creation, photo animation, voice-first databases, and more. All built with tools like Lovable, Cursor, and similar AI code generators.
We like the speed. What we didn't like was finding out, sometimes weeks after launch, that something was quietly broken.
In early 2026, we launched one of our newer products. Three weeks in, a team member noticed that the Supabase anon key was exposed in client-side JavaScript, paired with a Row Level Security policy that was too permissive. Anyone with basic dev tools knowledge could have read other users' data.
Nobody had exploited it. We got lucky. But it sat there for 21 days before anyone looked.
That was the moment we stopped treating post-launch review as something we'd "get to eventually."
We went back and systematically checked every product we'd shipped in the previous three months. Across 8 projects, the same categories of issues kept repeating.
Security: Exposed API keys or tokens in client bundles (5 of 8 projects). Overly broad RLS policies. Missing rate limiting on public endpoints.
SEO: No meta descriptions, missing Open Graph tags, broken sitemaps, pages that returned 200 but rendered empty shells without JavaScript. Several products were effectively invisible to search engines.
Performance: Unoptimized images at full resolution. Unused CSS/JS bundles on every page load. Lighthouse scores in the 30-50 range on mobile.
Accessibility: Missing alt text, no keyboard navigation, insufficient color contrast. One app had zero ARIA labels across 14 interactive elements.
Code quality: Duplicated components, dead code paths from earlier iterations the AI hadn't cleaned up, inconsistent error handling where some endpoints threw and others returned null silently.
None of these were edge cases. AI code generators produce functional code fast, but they don't audit their own output. They don't check whether that Supabase key should be in the client bundle. They don't verify that the sitemap actually lists all routes.
Our first internal audits were prose documents. 15-page PDFs walking through every finding. Nobody read them. The developer assigned to fix things would open the PDF, skim for red highlights, and close it.
So we restructured. Each audit now scores five dimensions on a 0-100 scale: Security, SEO, Performance, Accessibility, Code Quality. Under each score, findings are sorted by severity (critical, high, medium, low). Each finding has a one-line description, the root cause, and a concrete fix.
The goal was simple: a developer should be able to open the report, see the worst problem, and start fixing it in under two minutes. If they need ten minutes of reading first, the report has failed.
After running this across our own portfolio and then offering it externally, patterns became clear.
Across the first 30 audits (our projects plus external):
After fixes based on the prioritized report, projects typically moved 20-35 points on the aggregate score within a week.
We figured other teams shipping vibecoded projects were hitting the same blind spots. The tooling to catch these issues exists (Lighthouse, OWASP ZAP, axe-core, sitemap validators), but nobody runs all of them together, maps the results to a shipped product's priorities, and tells you what to fix first.
That's what Audit Vibe Coding does. You submit your project URL. It scores security, SEO, performance, accessibility, and code quality. You get a prioritized list of fixes, not a 15-page document.
Audit Vibe Coding is a professional audit for AI-generated (vibecoded) projects — it scores security, SEO, performance, accessibility and code quality and returns prioritized fixes.
Check it out: https://auditvibecoding.com
Building this changed how we ship. We now run a check before every launch. It added about 30 minutes to our process, but we haven't had another "three weeks with an open security hole" since.
If you're shipping vibecoded projects, you almost certainly have issues across these five areas. We did, and we were specifically looking for them.