GUIDE

Adding a login without getting it wrong

At some point the app needs to know who's using it, and you ask your AI for a login. It will happily build one from scratch: an email field, a password field, a table to store them. That version usually works on the first try and is the single most dangerous thing in the project, because passwords stored by an improvised login are generally stored badly, and you find out when someone else reads them.

The fix is boring and free. Use something that already does accounts, and let your AI wire your app to it.

Your four real options

1. Sign in with Google (or GitHub, or Apple)

No passwords exist in your app at all. The other service confirms who the person is and hands you back an email address. Least code, least risk, and most people already have the account. Downside: you're asking users to connect an account they may not want to link.

2. A magic link by email

The person types their email, gets a link, clicks it, they're in. Again no passwords. It fails in the ways email fails: links land in spam, corporate filters click them early and burn them, and people on a phone open the link in a different browser than they started in. Fine for most small apps, mildly annoying for some users.

3. An accounts service doing passwords properly

Supabase Auth, Clerk, Auth0 and similar handle passwords, resets, verification and the sessions behind them. You get a normal email-and-password login without your app ever storing a password itself. All of them have a free tier that covers a first project comfortably.

4. No login at all

Worth considering seriously. If the app doesn't need to remember anyone between visits, accounts add work, a privacy obligation and a support burden for nothing. Plenty of useful things never ask who you are.

The prompt to paste

I want to add user accounts to this app. Do not write your own password handling or store passwords in my database. Use an existing auth service instead. Before writing any code: tell me which option fits this app, what I need to sign up for, and which values I'll have to paste in. Then explain how you'll keep each user's data separate, so one logged-in person can't read another's.

The four checks before real people use it

  1. Log in as two different people. Make two accounts, put data in each, and confirm neither can see the other's. This is the failure that actually happens, and it is invisible while you're testing alone.
  2. Try the address bar. Copy a page URL that should need a login, open it in a private window, and see whether it loads anyway. Hiding a button is not the same as requiring an account.
  3. Run the reset. Click "forgot password", end to end, with a real inbox. Broken resets are the most common support message a small app gets.
  4. Check what's in the page. Your login service gives you two kinds of key: one safe to ship in the app, one that must stay on the server. If the powerful one is in the files you publish, anyone can read every account. Our free scanner checks a live site for exactly this.

Before you change the login on a live app

Swapping how people sign in touches the part of the app where mistakes lock everyone out at once, including you. Publish it knowing you can put the working version back in one click, and run the two-account check on the live site rather than only the preview.

Plyo is the home for AI-built projects — every version saved, one click to undo, one click to publish, plus a safety check, visitor counts and backups. Free to start: 3 projects, no card needed.

Give your project a home