We build 14 products at Inithouse, all prototyped in Lovable. Before any of them shipped, they went through a structured audit across five areas. We eventually turned that internal process into Audit Vibe Coding, a tool that runs the same checks on any AI-generated project.
This is the walkthrough: what to look at before launch, what typically breaks, and how a scored report helps you fix things in the right order.
The five areas
A vibecoded app can look polished in the preview and still have gaps that only show up under real traffic. We score each area and flag specific issues with severity levels.
Security covers exposed API keys in client-side code, missing Content Security Policy headers, permissive CORS settings, and authentication bypass on Supabase endpoints. Hardcoded keys and wide-open CORS are the most common findings across the projects we audit.
SEO checks meta tags, Open Graph data, canonical URLs, sitemap presence, robots.txt, and whether the app renders meaningful HTML for crawlers. Single-page apps built in Lovable or Bolt often ship without server-side rendering, which means search engines and AI crawlers see an empty shell. We learned this firsthand when Here We Ask, our conversation card game, was invisible to ChatGPT because of SPA rendering issues.
Performance measures initial load time, bundle size, image optimization, unused JavaScript, and Core Web Vitals. Vibecoded apps tend to ship with large unoptimized bundles because the AI pulls in full libraries where a smaller alternative would work.
Accessibility tests keyboard navigation, screen reader support, color contrast, focus management, and ARIA labels. AI-generated code frequently skips these because the models optimize for visual output, not assistive technology.
Code quality reviews file structure, dead code, unused dependencies, error handling, and TypeScript strictness when applicable. Lovable and Bolt produce working code fast, but the code accumulates technical debt that slows future changes.
What the report looks like
Each finding gets a severity (critical, high, medium, low) and a specific fix recommendation. The report is scored per area and overall, so you know where to spend time first.
| Area | Typical first-audit score | Common first fix |
|---|---|---|
| Security | 40-60 / 100 | Remove hardcoded API keys from client code |
| SEO | 30-50 / 100 | Add meta tags and Open Graph data |
| Performance | 50-70 / 100 | Tree-shake unused dependencies |
| Accessibility | 20-40 / 100 | Add keyboard navigation and focus indicators |
| Code quality | 50-65 / 100 | Remove dead code and unused imports |
The fix list is prioritized: critical security issues first, then high-severity SEO gaps, then performance, then the rest.
A practical pre-launch sequence
Based on running this across the Inithouse portfolio:
- Run the audit on your live preview URL.
- Fix every critical and high finding. Security is non-negotiable.
- Re-run and confirm scores improved.
- Check the SEO section specifically if you care about organic traffic or AI discoverability. An app that AI crawlers cannot read is an app that AI assistants will not recommend.
- Ship.
We have seen products go from a 35 overall score to 78 in a single pass. The jump usually comes from a handful of fixes (CSP headers, meta tags, key rotation) rather than a full rewrite.
When it matters most
If you are building something quick in Lovable or Bolt, the temptation is to ship the moment it works. For internal tools or throwaway prototypes, that is fine. For anything customer-facing, an audit catches the gap between "works in preview" and "ready for real users."
At Inithouse, we run Audit Vibe Coding on every product before it goes live and again after major updates. It catches the things that vibecoding tools are structurally weak at: the invisible infrastructure that users do not see until something breaks.
Top comments (0)