Most AI-built apps sign people in with Supabase (Lovable, Bolt, v0 and many apps from Cursor or Claude Code), Firebase (Antigravity), Clerk, or the builder’s own login (Replit, Base44). The provider pages cover each in depth: Supabase problems, Firebase problems. This page covers what generated apps add on top.
It works for you, and no one else
You built the app, so you’re on the Supabase project’s team, you’re probably still signed in, and you test on the domain the builder showed you. A tester has none of those:
- The email service only emails you. Supabase’s built-in sender delivers only to the project’s team, at most 2 emails an hour. Set up custom SMTP. On Lovable Cloud, check the sending limits in Auth settings.
- You’re already signed in. A broken sign-up still looks fine to someone with a session. Test in a private window, with an address that has never been used.
The link opens the preview, or localhost
The email’s link is built from the app’s public address setting. If it was left at http://localhost:3000, or set to a preview link that changed on the next deploy, people land on a page that doesn’t open. On Lovable Cloud, Lovable sets it when you publish unless you’ve set one yourself; on your own Supabase project, it’s the Site URL. Set it to the published domain and list previews under Redirect URLs. More in why emails link to localhost. Proxy Mail QA flags these links on the address’s row.
Clicking the link signs nobody in
The link brings a code back to your app, and a page has to swap it for a session. Generated apps often send the link to the home page, which ignores the code, so the person arrives signed out and assumes it failed. Ask for a page that finishes sign-in (often /auth/callback) and points the email’s link at it. With Supabase, testers should open the link in the browser they signed up in: why.
“Check your email”, whatever happened
Generated sign-up forms often show the same success message whatever the provider answered. Behind it:
- The address already has an account. Supabase answers as if sign-up worked and sends nothing, so it doesn’t reveal who has an account. The app should say: “If that address is new, we’ve sent a link. Already signed up? Sign in or reset your password.”
- It was too soon. A second request within 60 seconds is refused, and the app hides the error.
- Email confirmation is off. The account was created and signed in, with no email at all.
Ask the builder to show the provider’s error when there is one, and to word the success message so it’s true either way.
The reset email has nowhere to go
A password reset link signs the person in, then the app has to show a “choose a new password” form. Generated apps often skip that page, so the person is signed in with their old password and no way to change it. Ask for a reset page that the link opens, and test it end to end: Test password reset emails.
Forms that turn away real people, or let bad data through
- Too strict: some generated forms reject addresses with a
+, capitals or a newer domain ending such as.dev, or names with an apostrophe. Unusual addresses and unusual names and passwords list what to try. - Too loose: the form accepts a value the database won’t, and sign-up fails with “Database error saving new user” when the app’s
profilestable rejects it. A 255-character name or an empty username finds these.
Confirmation was switched off while building
Builders sometimes turn off email confirmation so sign-up is quicker to try, and it stays off at launch. Then anyone can sign up with an address they don’t own, and you never see whether the confirmation email works. Switch it back on before you share the app, and test it with an address that receives mail.
The agent says it’s done
A coding agent checks that the form submits, not that the email arrives or its link works. Connect the Proxy Mail QA MCP server and ask it to sign up with a new address, wait for the code or link and finish the sign-up. It reads only the code or link, never the email’s text.
Copy-paste prompts for your builder
Check our login setup: list every email the app sends (sign-up confirmation, magic link, password reset, email change), which service sends it, and the page each link opens. Flag any link built from localhost or a preview address, and any link that opens a page that doesn't finish signing in.
Add a page that finishes sign-in when someone opens the link in a confirmation or magic-link email, and a page to choose a new password after a reset link. Point the email links at them.
On sign-up, show the error the login service returns, if any. When it succeeds, say: "If that address is new, we've sent a link. Already signed up? Sign in or reset your password." Never say an email was sent when it wasn't.
Your builder’s guide
Each one covers its own login options and settings: Lovable, Bolt, v0, Replit, Base44, Antigravity, Cursor and Claude Code. Not sure which login yours uses? Login methods compared.