Your Lovable or Bolt app's login or Supabase database is broken: what to hand a freelancer

The short answer

When the login or the database of a Lovable or Bolt app breaks, the screens usually look fine. The problem sits in a part you never saw while building: the Supabase project behind the app, its authentication settings, its access rules and its keys. That is good news for the fix, because these are small, well-known areas, and bad news for the brief, because “login is broken” tells a developer almost nothing.

Before you hire, collect four things: what exactly happens, step by step, for each problem; access to the accounts, in your name, that you can remove later; a safe copy of the code and the data; and the list of keys and settings the app uses, names only. Then ask for a fix that includes a written check of who can read which data. The brief on the AI-built app job page has the general fields; this guide fills them in for the login and database side.

The four usual breakages

These are the patterns a fixer will look for first. You do not need to diagnose them, only to describe what you see accurately enough that they can.

What you see	What it usually is
Sign-up email arrives, but the link opens a blank page, an error or localhost	Authentication settings still point at the preview or a local address
Logged-in users see an empty page or “no data”, though the data is in the table	The database’s access rules block the read, or the app queries as the wrong user
A user can see or change another user’s records	Access rules missing or too open on that table
Works in the builder’s preview, fails on the live domain	Settings or keys present in one place and missing in the other

The first one is a settings issue. According to Supabase’s documentation, the Site URL is the default address people are sent back to, and it is “critical for email confirmations and password resets”. Addresses not on the project’s allowed redirect list are rejected. The default Site URL is a local development address, meant to be changed before deployment. If your app moved from a preview to your own domain and nobody updated these, the login emails point at the wrong place.

The third one is the one to worry about. Supabase describes row level security as “granular authorization rules that run inside the database”, and warns that a table in an exposed schema without it “is readable and writable by any role with a grant on it”. An AI builder can create tables quickly. Whether each one got the right rules is exactly what a demo with one user never tests.

Why “works in preview, broken live” is so common

I do not run an app with user logins. I do run unattended jobs that work perfectly when I start them by hand and fail when something else starts them, and the cause has the same shape as the fourth row above.

One of my publishing jobs kept its account ID and access token in a settings file next to the code. When I ran it by hand, my terminal loaded that file first. When the scheduler ran it, nothing did, so the token was simply empty, and the job failed quietly, only when unattended. The fix was to make the job load its own settings and to add a dry-run mode that prints whether each required setting is present. The explainer on environment variables and secrets has the longer version.

An AI-built app has the same split: the builder’s preview has its settings, the live host has its own. A key present in one and missing in the other produces exactly the “works there, not here” symptom. That is why the brief below asks for the list of required settings and a check that each one is set on the live host.

What to collect before you message anyone

If the accounts are not in your name yet, sort that first. Everything else depends on it, and who should own the accounts walks through the order.

A brief block you can copy

What it is. [One paragraph: what the app does, who uses it, built with Lovable / Bolt, data in Supabase.] Problems. [Each one with steps to reproduce, where it happens, what should happen instead.] Access. Repository [link], Supabase project on my account. I will invite you with removable access. Settings. The app uses these keys and settings: [names]. Please list any that are missing on the live host. Scope. Fix the problems above. Review the login settings (Site URL, redirect addresses) and the access rules on every table that holds user data. No redesign. Hand-back. Every change in my repository with a note per fix. A written table: each table, who can read it, who can change it, checked yes/no. Acceptance. The problems no longer reproduce on the live domain, and the access tests below pass. Keep editing. I will keep editing in [tool]: yes / no.

The table in the hand-back line is the most useful thing you will get from this order. It turns “the database is secure” into something you can read and check.

How to accept it

Tests 3 and 4 take five minutes and catch the most expensive kind of mistake. The acceptance checklist for a fixed AI-built app has the wider list if the order covered more than login and data.

Who to hire, and what it costs

You want a fixer, not a builder. On the AI-built app job page, the vetted gigs started at $100 to $250 when checked in September 2026, and a starting package usually covers a scoped fix or a review. Teamseven is listed for fixing errors and broken modules in vibe-coded apps, which suits a scoped bug list like the one above. Muhammad Tariq fixes broken Replit, Lovable and Bolt apps. If you are unsure how big the problem is, Amish Sohail offers a low-cost first review before you pay for fixes.

What moves the price: the number of tables holding user data, whether real users are already in the database (fixes must not lose or expose anything), payments or file uploads tied to the login, and whether you need to keep editing in the builder afterwards.

I have only ever checked my own projects myself; I have never paid for an outside security review. For anything holding other people’s personal data, the security check before launch explains what a fuller review adds.

Where it goes wrong anyway

• The builder undoes the fix. A later prompt in Lovable or Bolt regenerates a part and loosens a rule. Re-run tests 3 and 4 after any big change; this guide on apps that break after every change covers how to stop it.
• The live domain changes. A new domain or subdomain needs adding to the redirect settings again. Put it on the same note as the keys.
• A new table appears. Every new table that holds user data needs its own access rules. Ask the fixer to write that rule into the project’s instructions for the AI tool.

Wrap-up

A broken login looks like a big problem and is usually a small one in a place you never looked. Describe each symptom exactly, keep every account in your name, and ask for the one deliverable that matters most: a written table of who can read and change each piece of data, checked with two test users before you pay.