Multi-tenant SaaS

This is the starting point for a real SaaS — the kind where strangers sign up, each gets their own private data, and you never want to see one customer's rows leak into another's. Normally that means building the scariest part of the stack first: an email-code login, passkeys, session cookies, a users table, and per-row scoping you have to get exactly right. Get it subtly wrong and it's a security incident.

Here it's already built and wired correctly. The platform's [auth] block mounts the whole end-user login flow — email one-time code, optional passkey, sessions — so the page ships with a working sign-in/sign-up screen you didn't write. Your data routes stay tiny: call auth.requireUser, then scope every query with WHERE user_id = $1. The included task manager shows the pattern end to end — list, create, update, delete — with each user seeing only their own tasks, enforced on every read AND every write (so a guessed id can't reach someone else's row).

It's the one foundation starter that uses [auth]. If you're building something owner-only or for a small invited team, the Personal App and Team App starters are a better fit — they use the platform's collaborator system and need no login at all. Reach for this one when you specifically need open public signup with isolated per-user data.

Copy & Launch it, rename `tasks` to whatever your users actually own — notes, expenses, projects, workouts — and you have the spine of a SaaS without having touched auth.