Skip to content

My App Has No Password Reset, How Do I Add One Before Launch?

6 min read

If your AI-built app has a login screen but no "forgot password" link, add one before real users sign up. The safe, standard fix is an email-link reset: the user enters their email, your auth provider sends a one-time link, and the link lets them set a new password. Most vibe-coded apps skip this, and the first person who forgets their password is locked out with no way back in.

Why this happens

When you asked your agent to "add login," it built exactly that: a form that takes an email and password and signs the user in. It did not build the flow for what happens when someone forgets, because you did not ask, and the demo worked without it. You tested with a password you remembered, so the gap never showed.

Password reset is a separate flow with its own screens and its own email. Agents build the happy path first. The recovery path is the part that quietly goes missing, and it is invisible until a real user hits it.

How to check

You do not need to read code to find out. Look at your own app:

  1. Open your login screen. Is there a "Forgot password?" link near the password field? If not, you almost certainly have no reset flow.
  2. Sign up a test account, then sign out and pretend you forgot the password. Try to get back in. If there is no path that does not involve you editing the database by hand, real users have no path either.
  3. Check your auth provider's dashboard for a password-reset email template. If Supabase, Firebase, Clerk, or Auth0 is set up but the reset email was never enabled or wired to a screen, the link goes nowhere.

The fix

Use your auth provider's built-in reset. Do not build your own token system.

  1. Add a "Forgot password?" link to your login screen that opens a small form asking only for the user's email.
  2. Call the provider's reset method when that form submits. On Supabase that is resetPasswordForEmail(email, { redirectTo }). Firebase has sendPasswordResetEmail. Clerk and Auth0 expose the same thing. This sends a one-time link to the user's inbox.
  3. Build the "set a new password" screen that the link lands on. It reads the token from the URL, shows two password fields, and calls the provider's update-password method. The provider verifies the token for you.
  4. Confirm the reset email actually sends. Providers throttle or sandbox email on the free tier, so a link that works for you may never reach a real user. Set up a real sender (Resend, Postmark, or your provider's SMTP) before beta.
  5. Test the whole loop end to end: request the link, open it from the email, set a new password, and sign in with the new one. Then confirm the old password no longer works.

The trap to avoid

Do not add "security questions" or a "reset password over the phone" step, and do not let a user reset a password by typing their email alone with no link. Security questions leak, and a reset that skips the emailed link means anyone who knows a user's email can take their account. The emailed one-time link is the security. It proves the person controls the inbox. Lean on your provider's version of it rather than inventing your own token handling.

Where this fits

A missing reset flow is the kind of gap that never appears in a demo and always appears the first week of beta, usually from the user you most wanted to keep. The free Readiness Report checks your auth flow for exactly these holes against your real project, and the Finishing Pass hands you the fixes in order. While you are in the auth flow, it is worth deciding whether you even need passwords for beta, covered in Google login or email and password, and whether to require email verification at sign-up.