Add teams to a Lovable app (TanStack Start, BuildBase sign-in)
One prompt that adds a workspace switcher, members and email invites to a Lovable app, and scopes your own tables by workspace.
Lovable can also connect to BuildBase itself while it builds: Use BuildBase in Lovable.
Each customer gets a workspace, a switcher in the header, and a members screen where an admin invites a colleague by email. Workspaces, members and roles live in BuildBase; your own tables stay in Lovable Cloud or Supabase, scoped by the workspace id. This page assumes the app already signs people in with @buildbase/sdk, as the Lovable guide sets up. If it signs people in with something else, such as Supabase or Clerk, read keep your existing sign-in first.
Before you start
A sender connected in the console, so invitation emails go out (connect a sender).
The prompt
The link opens a new Lovable project with the prompt filled in and not sent. For the app you already have, paste the prompt into that project's chat instead.
This app signs people in with BuildBase (@buildbase/sdk), set up as https://www.buildbase.app/guides/add-login-teams-and-paid-plans-to-a-lovable-app shows. If it does not, stop and tell me.
Read https://docs.buildbase.app/workspaces/overview.md first and do not invent endpoints.
- Add WorkspaceSwitcher from @buildbase/sdk/react to the header, and a Members button that calls openWorkspaceSettings('users') from useSaaSAuth().
- Give every table of mine a workspace_id column and filter every query by currentWorkspace._id from useSaaSWorkspaces().
- In TanStack Start server routes, check the workspace id from the request is in bb().workspace.list() from src/server/buildbase.ts before reading or writing its rows.
Do not create workspace, membership or role tables in Lovable Cloud or Supabase; BuildBase holds them.Where the secrets go
This job adds no new secret. BUILDBASE_CLIENT_SECRET stays where the guide put it: More > Settings > Secrets, never in .env and never with a VITE_ prefix. The server routes use the signed-in person's session cookie, bb-session-id.
The Lovable trap
Row-level security policies keyed to the old sign-in (auth.uid()) do not know who a BuildBase user is, because a BuildBase session is an opaque id, not a token Supabase reads. Rows vanish, or a query answers "permission denied". Read and write through server routes that check the workspace, as the prompt asks, or follow the guide's section on minting a Supabase-shaped token.
Then test it: sign in as a member of one workspace and change an id in the address bar. If you see another workspace's rows, a query is missing its workspace_id filter.