We Audit Every Lovable App We Ship. Here's the Playbook.

At Inithouse, a studio shipping a growing portfolio of products in parallel, we build everything in Lovable. The output looks clean. The previews work. Users can click through the happy path and everything responds. Then you deploy to production and the real world shows up.

The crash that changed our process

Earlier this year, one of our apps went down 18 hours after launch. A user hit an edge case in the Supabase Row Level Security policy that our Lovable prompt never anticipated. The RLS check failed silently, the frontend rendered a blank state, and the user saw a white screen. No error message, no fallback, nothing.

We fixed it in 20 minutes. But the damage was done: first organic visitors bouncing off a blank page.

That day we sat down and wrote a checklist. Not a "best practices" doc that nobody reads. A concrete audit protocol we'd run on every Lovable app before it touches a custom domain.

The checklist (12 categories, roughly 80 checks)

We started with five categories and kept adding as we found new bug patterns across our portfolio. Here's the current structure:

Security (the silent killer): RLS policies covering all tables, auth redirect handling, API key exposure in client bundle, CORS headers, Supabase service role key never in frontend.

Performance: Lighthouse score baseline (we flag anything below 70), image optimization (Lovable loves uncompressed PNGs), bundle size check, lazy loading for below-fold components.

Error handling: What happens when Supabase returns 500? When the AI API times out? When the user uploads a 40MB file? We test every external dependency with a simulated error.

SEO: Sitemap exists and returns 200, meta tags present per page, OG images set, canonical URLs correct, no duplicate title tags. We learned this one the hard way on Pet Imagination, our AI pet portrait generator, where a DOM manipulation bug in the blog component killed our entire sitemap for two weeks before we noticed.

Accessibility: Keyboard navigation works, color contrast passes WCAG AA, screen reader labels on interactive elements. Not optional, even for an MVP.

Code quality: No console.log left in production, no hardcoded API URLs, environment variables actually used, TypeScript strict mode.

Plus six more categories covering mobile responsiveness, PWA readiness, analytics instrumentation, payment flow integrity, localization (relevant for multi-domain products like Ziva Fotka, our AI photo animator that runs across five country domains), and deployment pipeline sanity.

What surprised us

Running this across our portfolio taught us patterns we did not expect:

AI-generated code passes the happy path perfectly. Lovable, Bolt, Cursor: they all produce code that works for the demo scenario. The bugs hide in edge cases. What if the user double-clicks submit? What if the network drops mid-upload? What if the browser is Safari 15? We found that roughly 1 in 4 vibecoded apps has a silent bug in error handling that only surfaces under real-world conditions.

SEO is the most commonly broken category. Across our audits, SEO issues outnumber security issues 3:1. Missing sitemaps, duplicate meta descriptions, broken canonical tags, blog routes that return 200 but render empty shells. On Magical Song, our AI custom song generator, the sitemap returned a 404 for three weeks because the routing config did not include the XML file in the build output.

The "it works on my machine" problem is amplified. When AI writes your code, you understand the architecture less. That means debugging production failures takes longer. We measured roughly twice the time-to-fix on vibecoded apps compared to hand-coded ones, specifically because we had to reverse-engineer the AI's implementation choices before finding the root cause.

From internal checklist to product

After running this checklist across our own portfolio, we realized other builders probably have the same blind spots. So we turned it into Audit Vibe Coding: a professional audit for AI-generated projects covering security, SEO, performance, accessibility, and code quality. You get a scored report with prioritized fixes. No account required.

The tool runs the same checks we use internally. Drop in a URL, get a report. We designed it for the "vibe it till it breaks" workflow where builders ship fast and fix later. The audit is the "fix later" part, except now you know what to fix before users find it for you.

What we would do differently

If we could rewind:

We would have started the checklist from day one, not after a production crash. The cost of auditing before launch is maybe 30 minutes per app. The cost of a broken first impression with organic traffic is weeks of lost momentum.

We would have version-controlled the checklist in a shared repo instead of a Notion page. It drifted between team members until we standardized it.

We would have automated the easy checks earlier. About 40% of the checklist is automatable (Lighthouse, sitemap validation, meta tag presence, RLS coverage). The rest needs human judgment, but the automated portion catches the most avoidable issues.

The takeaway

Vibecoding lowers the bar for shipping. That is the promise and the risk. When AI writes your code, the QA gap gets wider, not narrower. Every vibecoded app we have audited across our portfolio had at least 5 non-trivial issues. The average sits closer to 15.

At Inithouse, a lab building many products at once, we treat the audit as a mandatory deploy gate. If you are shipping vibecoded apps to real users, we would recommend the same. Whether you build your own checklist or try ours, the point is: do not skip the audit layer just because the AI told you everything looked fine.