Foundations — security, auth, database, cloud & AI

Before we build five tools that make daily work easier, we need one short lesson on the foundations underneath all of them. Every project after this uses some mix of the same five things: security, auth, database, cloud, and AI. Not every project needs every piece — and that choice matters more than the code you write.

Part 1 · Why start here

The hard part of building tools with AI is not the typing — Lovable will happily generate 500 lines of code from a one-sentence prompt. The hard part is knowing, before you prompt, what kind of app you're actually building.

• Does everyone see the same data, or only their own?
• Do you need users to log in, or is an email enough?
• Is data public, or is a leak a real problem?
• Do you need AI, or would a rule cover it?

The rest of this course is five real projects, each answering those questions differently. This lesson gives you the shared vocabulary so the projects read the same way in your head.

Part 2 · Security mindset

There is one rule that never bends: never trust the browser. Anything running in the user's tab — your React code, your API keys accidentally left in the bundle, the "isAdmin" flag you set in localStorage — is visible and editable to the person sitting at the screen.

The three real gates

• RLS (Row-Level Security) — rules on the database itself. Even if someone crafts a malicious request, the database refuses to return rows they shouldn't see.
• Server functions — code that only runs on the backend. This is where secret keys live and where you check "is this user allowed to do this?" before doing it.
• Input validation — never insert what a user typed straight into a query, an email, or an AI prompt without checking length and shape first.

Part 3 · Auth — when you need it

Auth means "the app knows who this person is because they proved it — usually with a password, a Google account, or a magic link to their email." Auth is not free: it comes with sign-in flows, password resets, session expiry, and support tickets. So the first question is always: do we need it at all?

Part 4 · Database — the shape of your data

A database is a set of tables. A table is a spreadsheet with rules — column types, required fields, and (crucially) policies that say who can read or write each row.

Three things to decide, in order

1. 1Shape

   What are the rows? One row per submission? Per user? Per activity? Sketch the columns before you prompt.

2. 2Ownership

   Every row belongs to somebody or nobody. If it belongs to a user, add a user_id column. If it belongs to "the public", say so explicitly.

3. 3Policies (RLS)

   For each of INSERT, SELECT, UPDATE, DELETE — who is allowed? Anonymous visitors, signed-in users, only the owner, only admins?

Roles live in their own table

When more than one person can do more than one thing (a normal user vs an admin), store roles in a dedicated user_roles table — never a column on the profile, and never localStorage. Check roles with a security-definer function like has_role(). We cover this deeply in Lovable Lesson 16.

Part 5 · Cloud — what the backend actually is

"Cloud" in Lovable means four services you can enable without setting up servers:

• Database — Postgres. Your tables live here.
• Auth — email/password, Google, magic links, plus session management done for you.
• Storage — file buckets (private by default) for uploads, images, and generated files.
• Server functions — small pieces of code that run on the backend, not in the browser. Where secrets and privileged logic live.

Part 6 · AI — when to reach for it

AI is not the answer to every feature. It's the answer when the input is messy, fuzzy, or open-ended and a rule would be impossible to write. Otherwise, a plain function is faster, cheaper, and predictable.

In this course we always call AI from a server function using the Lovable AI Gateway — never directly from the browser, never with the key in the bundle, and always with a request-length cap.

Part 7 · Start every project with a Power Prompt

Every project lesson opens with a Power Prompt — the five-block structure from the power-prompt course. Use it before you type anything into Lovable's chat.

Goal · Input · Layout · Features · Output. Five blocks. Fill each one in a sentence. Paste. The agent will nail it on the first try far more often than with "build me a thing that does the thing".

Foundations cheat sheet

• Browser = untrusted. Server = trusted. RLS is the line between them.
• No auth is a valid choice — as long as you accept that identity is unverified.
• Roles live in user_roles, never on a profile column, never in localStorage.
• Secrets read from process.env inside server functions. Never in src/.
• AI is for fuzzy inputs. Rules beat AI for anything a WHERE clause could solve.
• Every project starts with a Power Prompt, not a chat message.