Lovable AI Vibe Coding Cleanup Guide: Fix Bugs, Errors & Failed Deployments (2026)

Your Lovable AI app crashes on deploy. The Supabase queries throw infinite recursion detected. The Vercel build log is a wall of red. Vibe coding got you 80% of the way — the last 20% (bugs, errors, failed deployments) is where most founders stall. Since 2016, we have helped founders ship 500+ apps in 40+ countries, and Lovable cleanups are now a weekly engagement for our team. This is the consolidated guide to the cleanup work we actually do — every common bug, with the exact code that fixes it.

Quick Answer

What is Lovable AI vibe coding cleanup? The process of reviewing, fixing, and refactoring code that Lovable AI (and similar prompt-to-app tools) generates, so the app actually deploys, runs, and scales in production.

Why does Lovable AI code break? Lovable generates code per prompt without seeing the full architecture. Iterative re-prompts accumulate dead code, missing env vars, broken Supabase RLS policies, missing CORS headers, and TypeScript loose ends.

Who needs this guide? Founders, indie hackers, designers-turned-builders, and any non-developer pushing a Lovable AI project to a real domain with real users.

What does this guide cover? 12 most common Lovable bugs with broken and fixed code, Vercel and Netlify deployment troubleshooting, a step-by-step cleanup checklist, best practices, and a decision framework for when to hire a developer.

Key Takeaways

• Lovable AI generates a React + Vite + TypeScript + Tailwind + Supabase stack that almost works but rarely deploys clean.

• Most bugs cluster around env vars (Vite uses import.meta.env, not process.env), Supabase RLS, and missing edge-function CORS.

• Failed Vercel and Netlify deployments are usually TypeScript build errors, missing env vars, or SPA 404s on deep links.

• Use a SECURITY DEFINER function to fix RLS infinite recursion.

• Always run npm run build locally before pushing — Lovable does not.

• Conditional hook calls cause runtime crashes — use React Query's enabled option instead.

• Auth signup without an on_auth_user_created trigger leaves orphan auth users.

• Memory leaks come from un-cleaned-up Supabase realtime channels.

• You can clean up most Lovable apps in 1–3 days once you know the patterns.

• Plan to budget 2–4 weeks of developer time before paid-user launch.

Quick Facts: Lovable AI Cleanup

MetricTypical ValueCommon bug count per project8 – 25Cleanup time (small MVP)1 – 3 daysCleanup time (mid SaaS)1 – 2 weeksCleanup time (feature-rich app)2 – 4 weeksGenerated stackReact 18 + Vite + TypeScript + Tailwind + SupabaseTypical deploy targetsVercel, Netlify, Cloudflare PagesHighest-risk areaSupabase RLS + Auth flowLowest-risk areaUI components (Tailwind / shadcn)

Why This Matters

In our experience working with non-technical founders, the gap between "Lovable preview works" and "live app users can sign up for" is the single biggest source of stall. Founders spend weeks fighting the same five bugs because the error messages are misleading and the fixes are scattered across Discord threads. This guide consolidates the fixes that actually work in production into one place.

What Is Lovable AI Vibe Coding?

Lovable AI (lovable.dev, formerly GPT Engineer) is a browser-based AI coding platform launched in 2023 from Stockholm. You describe an app in chat — "build a task tracker with login and Stripe billing" — and Lovable scaffolds a complete React + Vite + TypeScript + Tailwind + Supabase project, then iterates on prompts to add features. The phrase "vibe coding" was popularised by Andrej Karpathy and describes a workflow where you describe the vibe of what you want rather than writing each function.

It is one of several prompt-to-app tools competing with Bolt, v0, Cursor Agents, and Replit Agent. The output is real code committed to GitHub — not a black box — which is what makes cleanup possible in the first place.

Why Lovable AI Code Needs Cleanup

Lovable is great at the first 50 prompts and progressively worse after that. Five structural reasons:

1. Prompt-scoped context. Each prompt sees only a partial view of the codebase, so the AI re-implements helpers that already exist and forgets policies that already work.

2. No type-checking pre-commit. Lovable rarely runs tsc --noEmit, so TypeScript errors accumulate until the build breaks.

3. Loose Supabase patterns. RLS policies are often missing, recursive, or too permissive; CORS is forgotten on edge functions; triggers are skipped.

4. Vite vs Node env-var confusion. The AI hallucinates process.env usage that works in Node but not in the browser.

5. No deployment dress rehearsal. The Lovable preview is not a production build, so SPA routing, env vars, and asset paths only fail on first real deploy.

None of these are reasons to avoid Lovable — they are reasons to budget 1–3 days of cleanup before launch.

The 12 Most Common Lovable AI Bugs (With Code Fixes)

Bug 1: "process is not defined" Browser Error

Symptom: The browser console shows Uncaught ReferenceError: process is not defined on page load. The app freezes on a blank white screen.

Cause: Lovable generated Node-style process.env reads, but Vite (the bundler Lovable uses) exposes env vars through import.meta.env. Only keys prefixed with VITE_ are exposed to the browser.

Broken code:

// supabase.ts — generated by Lovable
import { createClient } from '@supabase/supabase-js';

const supabaseUrl = process.env.SUPABASE_URL;
const supabaseKey = process.env.SUPABASE_ANON_KEY;

export const supabase = createClient(supabaseUrl, supabaseKey);

Fixed code:

// supabase.ts — fixed
import { createClient } from '@supabase/supabase-js';

const supabaseUrl = import.meta.env.VITE_SUPABASE_URL;
const supabaseKey = import.meta.env.VITE_SUPABASE_ANON_KEY;

if (!supabaseUrl || !supabaseKey) {
  throw new Error('Missing Supabase env vars. Check your .env file.');
}

export const supabase = createClient(supabaseUrl, supabaseKey);

Then rename your .env keys to start with VITE_:

VITE_SUPABASE_URL=https://yourproject.supabase.co
VITE_SUPABASE_ANON_KEY=eyJhbGciOiJIUzI1NiIs...

Bug 2: Supabase Client Returning Undefined

Symptom: TypeError: Cannot read properties of undefined (reading 'from') when any query runs.

Cause: The Supabase client was either never initialised, initialised twice, or initialised with missing env vars that silently fall through.

Broken code:

// utils/supabase.ts — broken
export const supabase = createClient(); // no args

Fixed code:

// utils/supabase.ts — single source of truth
import { createClient } from '@supabase/supabase-js';

const url = import.meta.env.VITE_SUPABASE_URL;
const key = import.meta.env.VITE_SUPABASE_ANON_KEY;

if (!url || !key) {
  throw new Error('Supabase env vars missing at build time.');
}

export const supabase = createClient(url, key, {
  auth: { persistSession: true, autoRefreshToken: true },
});

Then grep your codebase for createClient( — there should be exactly one call. Delete duplicates.

Bug 3: Supabase RLS Infinite Recursion

Symptom: Postgres error infinite recursion detected in policy for relation "profiles".

Cause: A row-level-security policy on profiles reads from profiles to check the user's role. The check itself triggers the policy, which triggers the check, forever.

Broken policy:

-- broken — recurses
CREATE POLICY "admins_can_view"
ON profiles FOR SELECT
USING (
  EXISTS (
    SELECT 1 FROM profiles
    WHERE user_id = auth.uid() AND role = 'admin'
  )
);

Fixed policy with a SECURITY DEFINER function:

-- 1) Function runs with the function owner's privileges
CREATE OR REPLACE FUNCTION public.is_admin()
RETURNS BOOLEAN
LANGUAGE sql
SECURITY DEFINER
SET search_path = public
AS $$
  SELECT EXISTS (
    SELECT 1 FROM profiles
    WHERE user_id = auth.uid() AND role = 'admin'
  );
$$;

-- 2) Policy now calls the function, which bypasses RLS for the check
CREATE POLICY "admins_can_view"
ON profiles FOR SELECT
USING (public.is_admin() OR user_id = auth.uid());

SECURITY DEFINER tells Postgres to run the function as its owner (which has bypass-RLS rights), so the inner SELECT does not re-trigger the policy. Always set search_path explicitly to avoid search-path-injection attacks.

Bug 4: New Auth Users Have No Profile Row

Symptom: A user signs up successfully, but SELECT * FROM profiles WHERE user_id = auth.uid() returns zero rows. The dashboard breaks.

Cause: Lovable created an auth flow but forgot the trigger that auto-creates the public profiles row when a new auth.users row is inserted.

Fix — add the trigger:

CREATE OR REPLACE FUNCTION public.handle_new_user()
RETURNS TRIGGER
LANGUAGE plpgsql
SECURITY DEFINER
SET search_path = public
AS $$
BEGIN
  INSERT INTO public.profiles (user_id, email, created_at)
  VALUES (NEW.id, NEW.email, NOW());
  RETURN NEW;
END;
$$;

DROP TRIGGER IF EXISTS on_auth_user_created ON auth.users;
CREATE TRIGGER on_auth_user_created
AFTER INSERT ON auth.users
FOR EACH ROW EXECUTE FUNCTION public.handle_new_user();

Backfill missing rows for users who signed up before the trigger existed:

INSERT INTO public.profiles (user_id, email, created_at)
SELECT id, email, created_at FROM auth.users
WHERE id NOT IN (SELECT user_id FROM public.profiles);

Bug 5: TypeScript Build Errors Blocking Vercel Deploy

Symptom: The Lovable preview works fine, but Vercel's build fails with Type 'unknown' is not assignable to type 'string' or Property 'X' does not exist on type 'never'.

Cause: Lovable often skips type checks in preview but Vercel runs them via tsc. Common offenders: any, missing return types, and Supabase responses typed as unknown.

Broken code:

// broken
async function fetchUser(id: any) {
  const { data } = await supabase.from('users').select('*').eq('id', id).single();
  return data.email; // 'data' is possibly null
}

Fixed code:

interface User {
  id: string;
  email: string;
  name: string | null;
}

async function fetchUser(id: string): Promise<User | null> {
  const { data, error } = await supabase
    .from('users')
    .select('id, email, name')
    .eq('id', id)
    .single<User>();

  if (error) {
    console.error('fetchUser failed', error);
    return null;
  }
  return data;
}

Always run before pushing:

npx tsc --noEmit
npm run build

Bug 6: Edge Function CORS Error

Symptom: Browser console: Access to fetch at 'https://xxx.functions.supabase.co/yyy' from origin 'https://yourapp.com' has been blocked by CORS policy.

Cause: Lovable scaffolds a Supabase edge function but forgets the CORS preflight handler and the response CORS headers.

Fixed code (Deno / Supabase Edge Function):

// supabase/functions/my-fn/index.ts
const corsHeaders = {
  'Access-Control-Allow-Origin': '*',
  'Access-Control-Allow-Headers':
    'authorization, x-client-info, apikey, content-type',
  'Access-Control-Allow-Methods': 'POST, OPTIONS',
};

Deno.serve(async (req) => {
  if (req.method === 'OPTIONS') {
    return new Response('ok', { headers: corsHeaders });
  }

  try {
    const body = await req.json();
    const result = await doWork(body);

    return new Response(JSON.stringify(result), {
      headers: { ...corsHeaders, 'Content-Type': 'application/json' },
      status: 200,
    });
  } catch (err) {
    return new Response(JSON.stringify({ error: String(err) }), {
      headers: { ...corsHeaders, 'Content-Type': 'application/json' },
      status: 500,
    });
  }
});

In production, replace '*' with your real origin (e.g. https://yourapp.com) and add a comma-separated allowlist of trusted origins.

Bug 7: Conditional React Hook Crash

Symptom: Runtime error: Invalid hook call. Hooks can only be called inside the body of a function component or Rendered fewer hooks than expected.

Cause: Lovable wrapped a hook call inside an if branch — illegal under React's Rules of Hooks.

Broken code:

function Page() {
  const { user } = useAuth();

  if (!user) return <Login />;

  // ❌ conditional hook call — crashes on re-render
  const { data } = useQuery(['profile', user.id], () => fetchProfile(user.id));

  return <Profile data={data} />;
}

Fixed code:

function Page() {
  const { user } = useAuth();

  // ✅ call unconditionally, gate via 'enabled'
  const { data } = useQuery({
    queryKey: ['profile', user?.id],
    queryFn: () => fetchProfile(user!.id),
    enabled: !!user,
  });

  if (!user) return <Login />;
  return <Profile data={data} />;
}

The fix: every hook is called on every render. Conditional behaviour goes into the hook's options, not around the call.

Bug 8: Missing npm Dependency at Build Time

Symptom: Build fails with Cannot find module '@radix-ui/react-toast' or similar.

Cause: Lovable imported a package but did not add it to package.json (or removed it during a "cleanup" prompt).

Fix — install missing, prune unused:

# install the missing one
npm install @radix-ui/react-toast

# find all imports and confirm every one is in package.json
npx depcheck

# remove unused deps depcheck flagged
npm uninstall <package-name>

# regenerate the lockfile cleanly
rm -rf node_modules package-lock.json
npm install

Run npm run build locally before every push — it catches missing dependencies that the dev server tolerates.

Bug 9: Supabase Realtime Memory Leak

Symptom: The app slows down over time, the browser memory graph climbs, or the console warns about multiple subscriptions to the same channel.

Cause: A useEffect subscribes to a Supabase realtime channel but does not unsubscribe in its cleanup function. Every re-render adds another subscription.

Broken code:

useEffect(() => {
  supabase
    .channel('rooms')
    .on('postgres_changes', { event: '*', schema: 'public', table: 'rooms' }, handle)
    .subscribe();
  // ❌ no cleanup
}, []);

Fixed code:

useEffect(() => {
  const channel = supabase
    .channel('rooms')
    .on('postgres_changes', { event: '*', schema: 'public', table: 'rooms' }, handle)
    .subscribe();

  return () => {
    supabase.removeChannel(channel);
  };
}, []);

The same pattern applies to any imperative subscription — event listeners, intervals, web sockets — every useEffect that creates a resource must return a function that tears it down.

Bug 10: Env Vars Not Set on Vercel / Netlify

Symptom: Build passes locally, fails on the host with VITE_SUPABASE_URL is undefined, or the deployed site renders but every API call 401s.

Cause: Your local .env file is not pushed to GitHub (correctly), so the host has no idea what your env vars are.

Fix on Vercel:

1. Project → Settings → Environment Variables.

2. Add every VITE_* key for the Production, Preview, and Development scopes.

3. Trigger a redeploy — env vars only take effect on the next build.

Fix on Netlify:

1. Site settings → Environment variables → Add a single variable / Import from .env.

2. Set scopes the same way.

3. Trigger a redeploy.

Server-only secrets (Supabase service-role key, Stripe secret key, OpenAI key) must not use the VITE_ prefix — they should live in edge functions and only be referenced server-side.

Bug 11: SPA 404 on Direct URL Load

Symptom: Navigating around the app works, but loading https://yourapp.com/dashboard directly returns a 404.

Cause: The host serves the file at the URL path, but Vite SPA needs every unknown path to fall back to index.html so React Router can handle it.

Fix for Vercel — add vercel.json:

{
  "rewrites": [
    { "source": "/(.*)", "destination": "/index.html" }
  ]
}

Fix for Netlify — add public/_redirects:

/*    /index.html   200

Fix for Cloudflare Pages — add public/_redirects:

/*  /index.html  200

Bug 12: Tailwind Classes Disappear in Production

Symptom: Styles work in npm run dev but vanish after npm run build. Some classes render, others are missing.

Cause: Tailwind's content scanner did not see your classes at build time — either because they are dynamically composed as strings, or your content globs are wrong.

Broken (dynamic class assembly):

// Tailwind can't see 'bg-red-500' because it's a runtime string
const color = 'red';
<div className={'bg-' + color + '-500'} />

Fixed (explicit classes):

const colorClasses = {
  red: 'bg-red-500',
  green: 'bg-green-500',
  blue: 'bg-blue-500',
} as const;

<div className={colorClasses[color]} />

Then verify tailwind.config.ts globs are correct:

export default {
  content: [
    './index.html',
    './src/**/*.{js,ts,jsx,tsx}',
  ],
  // ...
};

Fixing Failed Lovable Deployments

Failed Vercel Deployment Checklist

1. Read the actual error at the top of the failed build log — not the summary at the bottom.

2. Run npm run build locally first. If it fails locally, fix it locally — do not push and hope.

3. Confirm all VITE_* env vars are set on Vercel for all three scopes.

4. Set Node version explicitly in package.json or Vercel project settings (Lovable defaults to Node 18+).

5. Disable type-checking only as a last resort by adding SKIP_TYPE_CHECK=true or relaxing tsconfig.json — better to fix the types.

6. Add the SPA rewrite from Bug 11 if direct URLs 404.

Failed Netlify Deployment Checklist

1. Confirm npm run build command and dist publish directory in netlify.toml or site settings.

2. Add public/_redirects for SPA routing.

3. Set Node version via .nvmrc or NODE_VERSION env var.

4. Add every VITE_* env var via the Netlify dashboard.

5. If using Functions, redeploy via Git rather than CLI so env vars propagate.

Step-by-Step Lovable AI Cleanup Checklist

Follow in this order. Each step is independent; skipping forward usually breaks the next step.

1. Connect to GitHub — give yourself a real git history before touching anything.

2. Clone locally and run npm install, then npm run dev. Confirm the app boots.

3. Replace every process.env. with import.meta.env.VITE_*. Rename keys in .env.

4. Run npx tsc --noEmit and fix every TypeScript error before deploying.

5. Audit Supabase RLS policies using the Supabase SQL editor — re-write any policy that selects from its own table.

6. Add the handle_new_user trigger if your auth flow expects profile rows.

7. Add CORS headers to every edge function.

8. Grep for un-cleaned useEffect subscriptions and add cleanup returns.

9. Run npx depcheck to find unused dependencies and missing ones.

10. Add SPA rewrites (vercel.json / _redirects).

11. Run npm run build locally and resolve every warning, not just errors.

12. Deploy a Preview on Vercel — click through every route in an incognito window.

13. Run a security review — confirm no service-role keys leaked client-side, no VITE_ prefix on secrets.

14. Promote to production only after the preview passes.

Best Practices to Stop Bugs Reappearing

• Commit after every working prompt — small commits make AI-introduced regressions trivial to find with git bisect.

• Run the production build at least weekly even if you do not deploy — it catches drift early.

• Use TypeScript strict: true from day one — looser settings hide bugs until deployment.

• Generate Supabase types with supabase gen types typescript so your client code matches your database.

• Never trust the AI on RLS — review every policy in the SQL editor before going live.

• Never let the AI rewrite a working file when the prompt was about a different file — pin the file context.

• Set up GitHub Actions CI running tsc --noEmit and npm run build on every PR.

Tools That Speed Up Lovable Cleanup

• tsc --noEmit — finds every TypeScript error without writing files.

• depcheck — finds missing and unused npm dependencies.

• ESLint with plugin:react-hooks/recommended — catches conditional hooks at lint time.

• Supabase CLI — diff local migrations against the cloud database to spot RLS drift.

• Lighthouse — production-build performance and accessibility check.

• React DevTools — debug re-render and subscription leaks.

• Vercel Preview Deployments — never push directly to production.

When to Hire a Developer (Instead of Continuing to Vibe Code)

Vibe coding works well for the first 80%. Past that, hire when any of these apply:

• You are about to launch to paying users — they expect uptime and you should not be debugging RLS at 2 a.m.

• You have compounding bugs — fixing one breaks two more.

• You have auth, billing, or PII — these are where a 1% bug becomes a 100% lawsuit.

• Your build time has crept past 3 minutes — that is a sign of accumulated dead code.

• You need features Lovable will not write well — payments webhooks, complex queues, file uploads with virus scanning.

Why Founders Trust Make An App Like

Founded in 2016, Make An App Like has shipped 500+ apps for founders across 40+ countries and reaches a 50,000+ founder audience through our builder-focused publishing platform. We were featured by TechCrunch as one of the leading app-development partners for non-technical founders. We have cleaned up dozens of Lovable, Bolt, v0, Cursor, and Replit projects — the patterns in this guide are the patterns that work in production.

Estimate the Cost of Your Cleanup or Custom Build

Get a fast budget estimate for Lovable cleanup, refactor, or full custom rebuild: https://makeanapplike.com/tools/app-cost-calculator

Skip the AI Slop With Ready-Made Software

If you would rather start from production-grade code than clean up vibe-coded code, browse our white-label and ready-made apps: https://makeanapplike.com/buy-white-label-apps

Conclusion

Lovable AI is a genuinely useful tool — it just leaves behind a predictable set of bugs. The 12 fixes in this guide cover ~90% of what we see in real cleanups: Vite env vars, Supabase client init, RLS recursion, auth-user triggers, TypeScript build errors, CORS, conditional hooks, missing deps, realtime leaks, host env vars, SPA 404s, and Tailwind purge. Work the checklist top to bottom, run npm run build before every push, and never trust the AI on RLS or secrets. Once you cross the cleanup line, vibe coding becomes a real superpower.

Frequently Asked Questions

1. What is Lovable AI vibe coding?

Lovable AI is a browser-based platform that generates React + Vite + TypeScript + Tailwind + Supabase web apps from natural-language prompts. "Vibe coding" describes the prompt-driven, vibes-first workflow — you describe what you want and the AI writes the code.

2. Why does my Lovable AI app keep breaking?

Lovable generates code per prompt without seeing the full architecture, so it accumulates dead code, missing env vars, RLS errors, and CORS misses. Iterative re-prompts add bugs faster than they remove them.

3. How do I fix "process is not defined" in Lovable?

Replace every process.env.X with import.meta.env.VITE_X, rename the keys in your .env file to start with VITE_, and rebuild. Vite only exposes VITE_-prefixed vars to the browser.

4. How do I fix Supabase RLS infinite recursion?

Move the role/permission check into a SECURITY DEFINER function with SET search_path = public, then call that function from the policy instead of re-querying the protected table directly. See Bug 3 above for the exact SQL.

5. Why is my Lovable Vercel deployment failing?

The three most common causes are: TypeScript build errors that pass locally because of looser settings, missing environment variables on Vercel, and SPA 404 on direct route loads. Fix env vars and add a vercel.json rewrite.

6. How do I add CORS to a Lovable Supabase edge function?

Add a corsHeaders constant, handle the OPTIONS preflight request explicitly, and spread the corsHeaders into every Response — including error responses. See Bug 6 for the full code.

7. Should I clean up Lovable code or rewrite from scratch?

Clean up if the app is under ~10,000 lines and the data model is right. Rewrite if you have major schema problems, a tangled auth flow, or compounding bugs in the same files after multiple re-prompts.

8. Can I use Lovable AI for production apps?

Yes, with cleanup. Many production apps run on Lovable-generated code, but only after a developer or developer-savvy founder fixes RLS, env vars, error handling, CORS, and the deployment pipeline.

9. How much does professional Lovable AI cleanup cost?

Light cleanup (1–3 days): $800–$3,000. Standard cleanup with security review and deployment fix (1–2 weeks): $4,000–$12,000. Full refactor to production-grade (2–4 weeks): $10,000–$30,000+.

10. How long does Lovable cleanup take?

A small MVP takes 1–3 days, a mid-sized SaaS takes 1–2 weeks, and a feature-rich app with auth, payments, and realtime takes 2–4 weeks of focused work.