Rebuilding Lovable's Auth Layer: A Step by Step For Non Devs

The auth layer is the first thing that breaks on a Lovable app and the last thing a non developer feels qualified to fix. A friend signs up and never receives the confirmation email. Password reset links go to a domain you do not own anymore. Someone logs in but lands on an empty dashboard because the profile row never loaded. The app worked last week, but the live site you have been sending traffic to is silently losing every new user at the doorstep. You did not write the code, and the codebase is a tangle of files named middleware and client and server that you are afraid to open.

Most founders at this point type "fix lovable auth" into Google, find a dozen thin posts that tell them to "check your Supabase redirect URLs" without explaining where, and either panic-hire a freelancer or abandon the launch. There is a middle path. You can audit and rebuild a Lovable project's auth layer yourself in an afternoon with Cursor, or you can hire with confidence because you know what you are paying for. This piece walks through both decisions, lists the Supabase dashboard panes that fail silently, names the three files you will regenerate and gives you the prompt to do it, and lays out a safe test protocol so you never break a live user account in the process.

Hire a Dev or Do It Yourself, the Honest Breakdown

A competent Next.js and Supabase freelancer will charge between seventy five and one hundred fifty US dollars an hour in 2026. An auth audit and rebuild on a small Lovable project, the kind with one users table, email and Google login, and a handful of protected routes, takes a capable dev two to six hours. Budget two hundred to eight hundred dollars total and a turnaround of one to five business days through Upwork, Contra, or a founder's network. The upper end assumes broken Stripe hooks, webhooks, or row level security policies need rewriting alongside auth, which is common because Lovable generates all of these in one pass and they often fail together.

The DIY path with Cursor, or Claude Code, or any decent AI code editor, costs twenty dollars a month for the tool and two to four hours of focused work if you are comfortable following a checklist. You are not writing code. You are reading a generated diff, clicking accept or reject, and running the app in your browser to see if the login works. The risk is real if your project is complex, because AI editors will happily rewrite files they should not touch. The risk is low if your project is small, you are only touching the three auth files, and you test in a preview environment before promoting.

The honest cutoff. If monthly revenue is under a thousand dollars, your user count is under fifty, and auth is the only thing broken, do it yourself. You will learn what the files do and not be held hostage by a dev's schedule next time. If you are processing real payments, have more than a hundred active users, or the break is tangled with RLS and webhook issues you cannot name, hire. The money buys you the diagnostic, which is harder than the patch.

The Six Supabase Dashboard Panes That Silently Fail

Before you touch a single file in the codebase, every auth investigation starts in the Supabase dashboard. Lovable wires your project to a Supabase backend at generation time, and ninety percent of the auth bugs founders blame on Lovable are actually configuration drift in Supabase. Open your project in supabase.com, click the Authentication icon in the left sidebar, and walk through these six panes in order.

URL Configuration is the most common failure point. The Site URL field holds the canonical production domain of your app, with no trailing slash, no path, and https in production. If you launched on a Vercel preview URL, later bought a custom domain, pointed it at Vercel, and never came back to Supabase, your Site URL is still the old vercel.app subdomain and every password reset link sends users to a subdomain they cannot access. Update it to your real domain. Below it, the Redirect URLs list needs every environment your app runs in. Production domain, staging or preview domains, and http://localhost:3000 for local development, each as a distinct entry. Avoid aggressive wildcards. Supabase supports a narrow subset of glob patterns, and incorrect wildcards fail closed.

The Providers pane lists every login method you have enabled. Email and password should be on. If you use Google, GitHub, or Apple login, each needs a matching OAuth redirect URI configured in the provider's own console, pointing back to your Supabase project's auth callback URL, which Supabase displays in the provider row. A mismatch here produces the most infuriating failure mode in auth, the one where the button works, the provider prompt appears, the user clicks allow, and then they are dumped on a blank error page because Supabase rejected the callback.

Email Templates is where the confirmation and reset emails live. Check the Confirm signup, Magic Link, and Reset Password templates. Each uses a variable like {{ .ConfirmationURL }} that Supabase substitutes at send time. If a previous contractor deleted the variable and hardcoded a URL, or the template points at a stale domain, users receive emails with dead links. The sender address needs to be verified. On the free tier Supabase sends from a noreply address that lands in spam for many Gmail users. Upgrading to custom SMTP through Resend, Postmark, or SendGrid is the single highest leverage fix for signup conversion on a live app.

Rate Limits is the pane that catches founders off guard. Supabase's built in email service throttles at a low threshold, typically four emails per hour per project on the free tier. If you tested signup a dozen times during development, you exhausted the limit and every subsequent attempt silently dropped. Moving to custom SMTP raises this ceiling. Sessions configuration, visible in the same area, controls how long a user stays logged in. Default access token expiry is one hour, default refresh token expiry is one week. Shortening either causes users to get logged out mid session, which reads as broken auth when it is actually working exactly as configured.

The last pane lives under Policies, sometimes under Database, Policies. Your users or profiles table almost certainly has row level security enabled because Lovable enables it by default, and it needs a SELECT policy that allows authenticated users to read their own row. The common failure is that RLS is on but no policy exists. Login succeeds, the session is valid, and the app's first query to fetch the profile returns zero rows. The code reads that as the user not existing and bounces them to login in a loop. Check that a policy named something like "Users can read their own profile" exists with the expression auth.uid() = id.

The Three Files Lovable Generates, and What Each One Does

Every Lovable Next.js project has an auth layer built from three files. Before rebuilding them, understand what each one is responsible for, because the naming is not self evident if you have never worked with the Supabase SSR package. If your paths differ slightly, the role of each file is the same, and Cursor will find them.

The first file is middleware.ts at the root of the project. Middleware runs on every single request your app receives, before the page renders. Its job is to grab the Supabase session cookie from the incoming request, refresh it if the access token has expired but the refresh token is still valid, attach the refreshed session to the outgoing response, and optionally redirect unauthenticated users away from routes that require login. When middleware breaks, the symptom is that users appear logged in on one page and logged out on the next, or they get bounced to the login page for no reason, or the session refuses to persist across a browser refresh.

The second file is lib/supabase/server.ts, sometimes under utils/supabase/server.ts. This creates the server side Supabase client, the one your server components and server actions use to read and write data on behalf of the logged in user. It reads cookies from Next's next/headers package, passes them to the Supabase client, and exposes a function the rest of your code calls. When this file breaks, server components fail to see the user even when middleware set the cookie correctly, which produces the "logged in but empty dashboard" bug. A related file, lib/supabase/client.ts, does the same job for browser code.

The third file is app/login/page.tsx, sometimes nested under a route group like app/(auth)/login/page.tsx. This is the actual login form users see. It calls supabase.auth.signInWithPassword for email login, or supabase.auth.signInWithOAuth for Google and other providers, and redirects to the dashboard on success. When this file is broken or stale, users type their credentials, click submit, and nothing happens, or a generic error appears with no useful message. A companion route, app/auth/callback/route.ts, handles the return trip from OAuth providers and exchanges the code Supabase sends back for a session.

The Cursor Prompt That Regenerates All Three, Safely

Open your project in Cursor. If you do not have Cursor, install it at cursor.com, sign in, and open your project folder through File, Open Folder. Accept the defaults on first launch. Once the file tree is visible on the left, press Cmd plus I on Mac or Ctrl plus I on Windows to open the Composer panel.

Paste this prompt exactly as written.

I have a Lovable generated Next.js app using the @supabase/ssr package. My Supabase URL and anon key are already in my .env.local as NEXT_PUBLIC_SUPABASE_URL and NEXT_PUBLIC_SUPABASE_ANON_KEY. I want you to rebuild from scratch these four files using the current Supabase SSR pattern, following the official Supabase Next.js App Router guide. The files are middleware.ts at the project root, lib/supabase/server.ts, lib/supabase/client.ts, and app/login/page.tsx. The login page should support email and password login and include a link to the signup and reset password flows. Do not modify any other file in the project. After each file, explain in one sentence what it does. Wait for me to accept each file before generating the next.

The phrase "wait for me to accept each file before generating the next" is load bearing. It slows Cursor down to a pace where you can read each diff, hit accept if it looks reasonable, and reject if Cursor starts pulling in unrelated changes. If Cursor ever proposes changes to files outside these four, reject the change and ask it to stay on scope.

After all four files are regenerated, ask Cursor one follow up. Run my project with npm run dev and tell me if the login page compiles without errors. Cursor will run the command, read the terminal output, and surface any import errors or type mismatches before you even open the browser. Fix those first. If the compile is clean, move to testing.

The Safe Test Protocol Before You Touch Production

Never test auth rebuilds against your live Supabase project with real users in the database. The safe pattern is to create a second Supabase project from the Supabase dashboard, copy your existing schema by running the SQL export from the original project's SQL Editor and running it against the new project, and point a Vercel preview branch at the new project's URL and anon key. In Vercel, create a branch in your repo called auth-rebuild, push the Cursor generated changes to it, and override the two Supabase environment variables in Vercel's project settings to point at the staging Supabase project only for that branch. Vercel will deploy the branch to a preview URL that is isolated from production.

Test five flows in order on the preview URL. Sign up a new account using a disposable email from a service like maildrop.cc, not your primary email and not a customer's email. Log out and log back in with the same credentials. Trigger the password reset flow and verify the email arrives and the link lands on a working reset page. If you use Google or GitHub login, test that flow and check that the account created matches the one you see in the Supabase Authentication, Users pane. Finally, navigate to a protected route while logged out and confirm you are redirected to login rather than seeing a crashed page.

Only when all five flows pass on the preview URL do you promote the branch. Merge it to main, let Vercel deploy production, and immediately test the same five flows on the live domain with a different disposable email. The reason for the second pass is that production uses the real Supabase project, real Site URL, real custom SMTP, and real OAuth redirect URIs, any of which might differ from staging.

When to Stop and Call WitsCode

The DIY path works for the clean case. You have a small Lovable app, your auth broke in a way the Supabase dashboard audit plus the three file regeneration can explain, and you have an afternoon to spend. It stops working when the rebuild does not fix the bug, which usually means the problem is not in the three files but in row level security policies, database triggers, webhook endpoints, or Stripe auth syncs that Lovable scaffolded alongside auth and that broke at the same time.

This is the WitsCode fix or upgrade engagement. We take the three file auth layer off your plate, audit every Supabase dashboard pane against your production domain, rewrite any row level security policies that are missing or misconfigured, and hand back a project where signup, login, password reset, OAuth, and profile loading all work on a disposable email we test together with you on a screen share. If the audit reveals the auth break is actually a symptom of a bigger scaffolding problem, we quote the upgrade separately so you can decide how far to go. Either way, you finish the engagement with a working auth layer, documentation of what was wrong, and a cleaner base for the next round of vibe coding.

Email hello@witscode.com with a link to your Lovable project and one sentence on what broke. We will come back with a fixed fee for the audit and a turnaround window within one business day.