You add login the same way you added everything else: by asking for it. Lovable, Base44 and Bolt each ship a login system you switch on from a settings panel or a single prompt. If you build with Claude Code or Codex, you name a login service and one prompt wires it in, sign-in pages included. In none of these paths do you write code. But the login screen is the easy half. What makes an app private is a second rule, “each person only sees their own things,” and that rule has to live in the parts of your app that visitors cannot touch. Most people who ask for login never ask for it.
What login does, and the thing it does not do
Login answers one question: who are you? The email and password, the Continue with Google button, the code sent to your phone, all of that is your app checking an identity. The technical word is authentication. There is a second question your app has to answer on every click: what is this person allowed to see and change? That is authorization. Checking someone’s name at the entrance and deciding which rooms they may open are two different jobs, and a builder that does the first will not do the second unless you say so.
Here is why that matters for your app. The pages people see run in their browser, on their own machine. The data lives in a database, a separate service that stores one row per saved item. When a page shows “your” items, something has to decide which rows to hand over. If nothing does, the page asks for every row, and a signed-in stranger sees everyone’s things. Hiding a button does not help, because a page that is only hidden can still be reached by typing its address. The rule has to be enforced on the server, the part of your app that runs on a computer visitors cannot open, and in the database itself. Keep that in mind for every path below.
Switching it on in Lovable, Base44 and Bolt
Each builder has this built in. The panels move with each update, so treat these as where to look, and check the builder’s own docs if something is not where I say.
- Lovable. With Lovable Cloud, its built-in backend, you add sign-up and login flows and manage your users from inside Lovable. Lovable can also run Sign in with Google for you, holding the Google credentials itself. If your project is connected to your own Supabase account instead, the login comes from Supabase and you ask for it the same way.
- Base44. Open Dashboard, then Settings, then Authentication. First set App Visibility: public with no login, public with login required, or private for invited people only. Then turn on the sign-in methods you want: email and password, Google, Microsoft, Facebook or Apple. New apps already come with login, register, forgot-password and reset pages you can restyle by chat.
- Bolt. Click the database icon at the top of the screen, then Authentication. Bolt Database offers email sign-up with confirmation and password reset, and a Continue with Google option that needs a Google client ID and secret from you. If you connected Supabase instead, prompt Bolt to add authentication with a sign-up and login screen.
Flipping the switch gives you the sign-in screen and a list of users. It does not, by itself, decide whose rows are whose.
If you build with Claude Code or Codex
Claude Code has no login toggle, because there is no product wrapped around it, just your project folder. Instead you name a login service and it wires that service in. Clerk, Supabase Auth, Auth0 and Auth.js all do this job. Each gives you finished sign-in and sign-up pages and a way to guard every page in the app, and switching between them changes the setup, not how your app uses identity. The service hands you a couple of keys, and those are secrets: they belong in a settings file on your computer, never inside a page.
The prompt you give asks for the same things the toggle gives you: accounts, sign-in, sign-out, and logged-out visitors sent to the sign-in page. And it leaves the same gap.
The half the login screen does not cover
Whatever you build with, the work that makes the app safe to put in front of strangers is the ownership rule. In plain words: once signed in, each person sees and changes only their own things, and that check happens on the server and in the database, not by hiding buttons in the browser. If some people should see more, an admin who can see every user and suspend an abuser, that is the same rule with a second tier, and the admin check has to run on the server too, so typing the admin page’s address does nothing for a regular user.
The fix takes a prompt rather than a rewrite: one that says the rule out loud, a builder that is made to explain how it enforced the rule, and a check you do yourself, because every builder says “done” whether or not the rule exists. The only proof that counts is a second account that cannot reach the first account’s things, however hard it tries.
You can learn more, and get the full prompts and the decision tables, in our course: Lesson 11, Who Are You? And What Can You Do?. The first lesson is free, no card.
In the next ten minutes: open your builder, find the login settings named above, and switch them on. If you build with Claude Code, pick a login service and ask for it by name. Then, before you publish, ask yourself whether anyone ever told the builder that each person only sees their own things. If nobody said it, nobody built it, and that is the next thing to ask for.