SignupCanaryLog in

Lovable login broke after an update

  • Lovable
  • Stripe

A Lovable app can look finished and still fail the only path that matters. The preview loads, the hero is polished, and the login form posts into an error toast nobody noticed because the last prompt was about the pricing cards.

What usually changed

Lovable rewrites the page that owns the form. Typical breaks:

  • The email input lost type="email" or its name.
  • The submit button is disabled until a field that is no longer rendered.
  • Signup and login now share one component, and the login branch never calls the auth client.
  • A new onboarding modal covers the form. The button is in the DOM and not clickable.
  • Email verification started redirecting to localhost.

Uptime checks stay green through all of these. The document returns HTTP 200.

Reproduce it the way a visitor does

  1. Open the deployed URL in a private window, not the Lovable preview.
  2. Create an account with an email address you have never used in that project.
  3. If the app says it sent a code or a link, wait for that message and open it.
  4. Log out, then log in with the same address.
  5. Only then click upgrade. Stop when Stripe Checkout appears. Do not pay.

SignupCanary runs that sequence in Chromium and keeps a screenshot of the first step that fails.

What to paste into Lovable

Describe the failed step, the URL, and the fact that a brand new email was used. Ask Lovable to fix the auth path without restyling the marketing page. A useful prompt names the field that was missing and says the pay button must not be changed.

After Lovable applies the edit, run the check again before you ship the next prompt. Login regressions tend to come back when a later prompt "simplifies the auth form".

Keep the form boring

Give the email and password inputs stable id values. Keep a real <button type="submit">. If you add a magic link, keep it as a second step that sends mail to the address just submitted, with a link on the deployed host.