Auth for People You Already Know

Almost every authentication system we build is designed for strangers.

We don't think of it that way, but it's true. When you build a registration form, you're assuming there's someone on the other side you don't know, don't trust by default, who could be anyone. From that assumption follows public registration, email verification, password reset, account recovery, rate limiting on everything. It's infrastructure designed to defend against someone you didn't invite.

For ReD Sposi, that assumption was wrong from the start.

The Problem in Reverse

The wedding guests are about a hundred people. I know all of them by name. Many aren't particularly technical — there are grandparents, distant relatives, friends who primarily use their phone for WhatsApp. None of them should have to register, choose a password, confirm an email, and then find that password four months later when they sit down at their table and want to upload a photo.

The authentication problem I was facing was the inverse of the standard one:

• The user set is closed and known in advance
• Nobody needs to self-register
• Identity is already established outside the system (the guest list)
• Access needs to be easy to recover, not to protect

In this context, email and password solve nothing. They only add friction.

The Invite Code as Identity

The solution was already in the wedding metaphor: the invitation.

Each guest gets a code — six alphanumeric characters, generated by the admin, associated with a name. The code is the identity. There's nothing else to know about you until you open the app and complete your RSVP.

POST /api/auth/login
{ "code": "ABCD12" }

→ { token: "eyJ..." }

No email. No password. No verification. If you have the code, you're in.

The generated JWT has a long expiry — months, not hours — because the use case doesn't involve frequent rotation. A guest opens the app every now and then for weeks, then uses it intensively on the wedding day. It makes no sense to ask them to re-login in the middle of the ceremony.

What the Admin Handles

The admin panel is where the actually privileged user — me — controls everything.

Each guest is a MongoDB document with a name, a code, and a structure that fills in over time: menu preferences, dietary restrictions, shuttle request, RSVP completed. The admin can create codes, regenerate them, deactivate them, see who has logged in and who hasn't.

This asymmetry is deliberate. ReD Sposi's "registration system" isn't a public form — it's me creating a document. I didn't build auth for strangers; I built a management tool for a list that already exists on paper.

Real-World Edge Cases

Designing for known people shifts the edge cases.

The code gets lost. The most common case. The solution isn't a recovery flow — it's a phone call. Or a WhatsApp message. Or me opening the admin panel. I didn't build self-service recovery because it wasn't needed: I'm always reachable and the set of people is small.

The code gets shared. A couple uses the same code from one person's phone. It happened. Technically, both show up as the same guest. In practice, for a wedding that's fine: the RSVP is per couple, not per individual. If I'd needed per-person granularity, I'd have generated two separate codes. The system design allows for it without any changes.

Someone wants to add a plus-one. This is the only case that requires real action. I create a new document, generate a new code, send it. Five minutes. I didn't build an "invite a friend" flow because managing the guest list is a human problem, not a technical one.

The Bigger Lesson

There's a common professional reflex: when you need to do auth, you reach for the standard library, implement registration, add password reset, configure refresh tokens. It's a checklist we've run so many times it's become automatic.

The problem is that checklist is written for a specific use case — and that use case might not be yours.

For ReD Sposi the right question wasn't "how do I do auth?" but "who are my users and what is their relationship with the system?". The answer — known people, finite set, simplicity above everything else — made ninety-five percent of the standard infrastructure unnecessary.

Recognizing when you're not building for strangers is an underrated skill. Most of the tools we use assume the hardest case. Often your case is much simpler — and the smartest thing you can do is not pretend otherwise.