Add auth without painting yourself into a corner

• Builders past the prototype stage who've been getting by with 'everyone's an admin'
• Teams about to onboard their first paying customers, contractors, or partner users
• Anyone whose app is going to need 'admin vs member vs viewer' soon and wants to set it up once, properly

Auth has two parts and most people only think about the first one. The easy part: how does someone prove they are who they say they are (email + password, Google, Microsoft, SSO). The hard part — and the one that paints you into corners — is what they're allowed to do once they're in (roles, permissions, scoping by tenant, audit trail). Pick the sign-in method that fits your user (consumers love Google; enterprises require SSO; internal tools tolerate email/password). Then design the access model on paper BEFORE you write a line of code. The access model is the part that's expensive to change later.

• Storing the user's role on the profile/user table. The first time someone exploits 'PATCH /profile { role: admin }', you'll wish you'd used a separate table.
• Anonymous sign-ups left enabled, then accidentally used as 'guest mode.' Anonymous users carry a real auth identity and confuse every analytics and permissions query later.
• Building roles before designing them — three weeks in you discover 'editor' actually means four different things to four different users.
• Sign-in works in dev but not in prod because redirect URLs / allowed origins weren't configured. Always test sign-in in prod before you tell users about it.
• Magic links that expire in 5 minutes for users who don't open email for hours.
• No way to sign a user out of all sessions when they say their account is compromised. By the time you need this, building it is panic work.
• Forgetting that 'remove user from org' should also remove their access on the next request — not 24 hours later when the JWT expires.
• Letting one Google account create an account, then a 'Sign in with email' account, then a 'Sign in with Microsoft' account — all for the same person. Account linking by verified email solves this if you build it early.

• Are users individuals, or do they belong to organizations? If organizations, that changes literally every permissions check.
• Will you ever need SSO? If 'maybe in 18 months,' build the data model to support it now even if the UI comes later.
• What's the recovery story when a user loses access to their email? 'Email me' is fine until it isn't.
• Do you need MFA, and for which roles? Often required for admin even when optional for end users.
• What's logged for audit — sign-ins, role changes, sensitive actions? Compliance asks for this; build it before they do.
• How do invitations work? Pre-created accounts vs invitation tokens vs 'just share the link' have very different security profiles.
• What's the offboarding flow when an employee leaves a customer org? Manual revoke, SCIM, or 'they'll figure it out'?

• There's a separate user_roles table; no role data lives on the profile/user table.
• RLS policies use a security-definer function (not direct table reads) so they don't recurse.
• I can sign up, sign in, reset password, change email, sign out of all sessions, and delete my account — and I've done each at least once in prod.
• Sign-in redirect URLs are configured for every environment (local, preview, prod). I tested the published URL, not just dev.
• An admin promotion requires explicit action (DB row, admin UI), not a self-serve toggle.
• Every sensitive action is in an audit log with timestamp, actor, and what changed.
• Removing a user from a team / org takes effect on the next request, not the next day.
• I tried to break it: signed in as a low-privilege user and confirmed I cannot reach admin pages, admin APIs, or admin data.

1. 1.Who are my users in 18 months — same as today, or do I expect orgs, partners, contractors, or enterprise SSO? That answer should drive the data model now.
2. 2.What's the worst-case if the wrong user sees data they shouldn't — embarrassing, expensive, or a breach notification? That sets how paranoid the model needs to be.
3. 3.Am I willing to pay for an auth provider (Clerk, WorkOS, Auth0) to skip building MFA, SSO, and SCIM myself? For B2B SaaS, the answer is almost always yes.
4. 4.Who's the 'break glass' admin if I lose access to my own account, and have I actually tested that path?
5. 5.Where do my roles get documented so a new teammate can read them without reading code?