How do I know a private page is really private?

Test it from a plain account, not your own. Log in as an ordinary user, then paste the address of an admin page directly into the browser. If the page opens, hiding the menu link never protected anything. That test takes a minute and is the only proof that counts.

What are user roles and do I need them?

A role decides what someone can see and do — owner, staff, customer. You need them the moment more than one kind of person uses the app. Without them, everyone who logs in is effectively equal, which is how private data ends up in front of the wrong person.

Should I build my own login system?

No. Use the platform's built-in account system. Passwords, resets and session handling are exactly the kind of thing that is easy to get subtly and dangerously wrong, and every major builder already provides them properly.

Authentication & Users

Add sign-up, login and user roles

Let people create accounts and log in, and protect the right pages.

Time: ~20 minutes Difficulty: Intermediate Works with: Base44 / Lovable / v0

When to use this

When your app needs accounts, a members area, or an admin-only section.

Before you start

An app that already exists (run the MVP prompt first if not).
Decide before you start: who can sign up (anyone, or only people you invite?), and what the different roles should be able to see. Write it down — the prompt asks for it.
Base44 and Lovable include login systems; on v0 you'll be connecting an outside service, which takes longer.

The prompt

Add secure user accounts to my app.
Outcome: visitors can sign up and log in, and the right pages are protected.
Requirements:
- Email + password sign-up and login, plus "Sign in with Google".
- A "forgot password" reset flow by email.
- Two roles — [regular user] and [admin] — where only admins can open [the admin area / these pages].
- A profile page where a user can edit [name, email, photo].
- Require login to view these pages: [list the private pages].
Must-haves (don't skip): validate all inputs, store passwords hashed, never expose secret keys in the frontend, and show clear messages for a wrong password, an email that already exists, and expired reset links. Add basic rate limiting on login and password reset.
Build it end to end, then tell me what changed and exactly how to test each flow.

Already building? Paste this into your project. Starting fresh? Open a free account with a compatible builder below.

Build it on

Start free with Base44 Read Review: Base44

Start free with Lovable Read Review: Lovable

Start free with v0 Read Review: v0 by Vercel

How we make money

What this creates

Sign-up, log-in and password-reset screens
A stored list of your users you can view
Role separation, so different people see different things
Protected pages that redirect anyone who isn't allowed in

Check it worked

Paste the prompt, wait for the build to finish, then confirm these — in plain language, no technical checks needed:

You can create a test account and log in with it
Signing out and back in works, and the password-reset email arrives
A logged-out visitor who opens a protected page is sent to the login screen instead of seeing the content
Your test user appears in your app's user list
If you asked for an admin role, your admin account sees admin things and a normal test account does not

Something missing? That's normal — ask for it in one short follow-up message rather than re-running the whole prompt.

Next steps

Check the locks actually hold

Immediately after login works

Review every page and every piece of data in the app and list which of them a logged-out visitor, a normal logged-in user, and an admin can each reach. Then fix anything a normal user or logged-out visitor can reach that they should not — the restriction must be enforced by the access rules, not by hiding links.

You'll know it worked when: You get a clear list of who can see what, and testing with a normal account confirms it.

Add a profile page

Once users exist and you want them to feel at home

Add a profile page where a logged-in user can see and edit their own details: [NAME, PHOTO, PHONE, WHATEVER APPLIES]. They can only ever see and edit their own profile. Add a link to it in the account menu.

You'll know it worked when: A logged-in user can update their own details and cannot open anyone else's profile.

Invite-only sign-up

For internal tools or private clients

Turn off public sign-up. Instead, let an admin invite people by email from an admin screen; invited people get a link to set their password and join. Everyone else who tries to sign up sees a short message explaining the app is invite-only.

You'll know it worked when: A stranger cannot create an account, and an invited email address can.

Watch out for

Test with a second account, not just yours. Everything looks permitted when you're the admin. Create a plain user and try to reach the admin pages — that's the real test.
Never build your own password system. Use the platform's built-in login; the prompt asks for exactly that. Homemade authentication is the most common serious mistake in AI-built apps.
"Hidden" is not "protected." Removing a link from the menu doesn't stop anyone typing the address. The prompt asks for real access rules — confirm they hold by testing with the logged-out account.

Platform notes

Base44 has built-in authentication and user management. Lovable can use native Lovable Cloud authentication or optional Supabase Auth. v0 builds the login and permission logic around a selected authentication provider, commonly connected through Vercel or the provider's SDK. On every platform, protect stored data as well as pages and test each role with an ordinary user account.

Spend fewer credits

Every builder charges you for the work its AI does — so the cheapest habit is thinking before you build. These six rules cut most of the waste, whichever platform you choose.

Plan in a free chat first. Sketch the whole thing in ChatGPT, Claude or Gemini — pages, features, what each form collects, what it should look like. Thinking there is free; thinking inside a builder is billed.
Start from a written prompt, not a sentence. "Make me a website" is the most expensive sentence in AI building. A complete first prompt — like the ones on this site — saves dozens of correction rounds.
Don't be lazy with the details. Every detail you leave out comes back as a correction you pay for. Business name, colors, every page, every form field, what happens after someone submits — put it all in the first prompt.
One change per message afterwards. "Fix the header, and the form, and the colors" produces a tangle that costs more to unpick than it saved.
Stuck? Stop patching. If the same fix fails about three times, don't send a fourth correction — describe the whole section's desired end state in one fresh message instead.
Start free. Upgrade when you need more. Use the free allowance to build and explore your first version. Upgrade when you need more usage or paid features, and check any connected service costs before launch.

The prompts on this page are written to do most of this work for you — that's the point of them.

Read the full guide

Related playbooks

Related prompts

Part of these kits

authentication login users roles security

Last reviewed: 2026-08-27