Grill Me

I'm starting from the root of the design tree. These questions don't depend on each other. Session mechanics, password storage and the threat model will hang off your answers.

I haven't looked at your codebase. If you tell me the stack, or point me at the repo, I'll check the facts myself and won't ask you for them.

❓ Q1 - Build or delegate?: Do you want to implement email and password auth yourself (hashing, sessions, reset flow)? The alternative is a hosted or library-backed option such as your framework's built-in auth, Auth0, Clerk, Supabase Auth or Firebase Auth. At 200 users, the cost of getting a custom implementation subtly wrong usually outweighs the cost of adopting a library.

➡️ Use your framework's mature auth library or a hosted provider. Don't hand-roll crypto or session handling. Email and password stays as the user-facing method.

❓ Q2 - What does login actually protect?: What can a logged-in user do that an anonymous visitor can't? Examples are posting recipes, editing or deleting only their own recipes, commenting, favoriting, or private recipes. Are there roles, such as an admin or moderator who can remove other people's content?

➡️ Anyone can browse. Login is required to create, and users can edit or delete only their own recipes. Add a single admin flag for moderation, and nothing more elaborate.

❓ Q3 - Existing data and users: Does the site already have content or "users" in some form, such as a name field or anonymous submissions? If so, how do existing recipes get attached to the new accounts?

➡️ Treat existing recipes as unowned. Let the admin assign them manually, or let an author claim one by email.

❓ Q4 - Email verification: Do you require users to confirm their email address before they can post?

➡️ Yes. Send a verification link, and allow browsing but not posting until it's confirmed. This stops typo'd addresses, which would lock people out of reset, and it stops spam signups.

❓ Q5 - Password reset: This is where "email and password" plans most often fail. Do you have a way to send transactional email reliably, such as Postmark, SES or Resend, with SPF/DKIM set up so messages don't land in spam? Will reset links be single-use and short-lived, around 1 hour?

➡️ Yes. Use a transactional email provider. Reset tokens are random, stored hashed, single-use and expire in 1 hour. Resetting a password also invalidates all existing sessions.

❓ Q6 - "Stay logged in" semantics: What does that mean to you? One option is a long-lived session cookie (say 30 days) that is HttpOnly, Secure and SameSite=Lax, backed by a server-side session you can revoke. The other is a stateless JWT. Should it be a "remember me" checkbox or the default behavior?

➡️ Use a server-side session with an opaque ID in an HttpOnly, Secure, SameSite=Lax cookie. Make it a 30-day sliding expiry as the default, because this is a low-risk site. Skip JWTs, since you can't revoke them easily and you gain nothing at this scale.

❓ Q7 - Abuse and brute force: Do you want rate limiting on login, signup and reset endpoints? For example, throttle per IP and per account, and add a CAPTCHA only if abuse actually shows up. Do you also want to reject known-breached or very weak passwords?

➡️ Yes to throttling on all three endpoints, with generic error messages ("invalid email or password") so accounts can't be enumerated. Set a minimum length of 10 and check against a breached-password list. Don't impose composition rules. Add a CAPTCHA only if abuse appears.

Once you've answered, the next round will cover password hashing and storage, CSRF, HTTPS and deployment, account deletion and data handling, and testing. Which of those apply will depend on what you pick for Q1.