Events and RSVPs for private clubs · In pilot
I Need To RSVP
Event invitations, seating, dues and payments for private social clubs — proven with one club, now becoming a product.
Role: Product design, flow design, money model, and direction of the agents that wrote it.
Timeline: In pilot with a private social club; productising as ineedtorsvp.com
- Kinds of information tracked
- 33
- Things it can do
- 202
- Admin screens
- 22
Distinct record types in the data model, from counting the table definitions in the schema file. Counted on 21 September 2026.
Separate operations the system can perform, from counting the HTTP endpoints registered in the server code. Counted on 21 September 2026.
Screens in the organiser's side of the product, counted as page components. Counted on 21 September 2026.
What was actually broken
A private social club runs its events on a spreadsheet, a group email, and an envelope of cash. It mostly works, right up until it doesn't: someone paid twice, someone was comped and nobody wrote it down, the seating chart lives in one person's head, and the treasurer spends a weekend a month reconciling.
The software that exists for this is either a consumer ticketing site — which does not understand members, dues, comps, or seats at a table — or an enterprise events platform priced for conferences.
The flow I designed
Two audiences with genuinely opposite needs, so they get genuinely different interfaces rather than one compromised interface with permissions.
Members never make an account. An invitation arrives by email, they tap the link, they RSVP. No password, no reset flow, no member emailing the club secretary because they can't get in. For an audience that skews older and only interacts a handful of times a year, a password is pure loss.
Admins get density, not friendliness. The admin side is a data-dense operator's tool — tables, keyboard flow, print views for the door. These are people doing an hour of concentrated work, not a 30-second task. Comfortable padding would just mean more scrolling.
Paying in person is a first-class path, not a fallback. Card-present terminal support, walk-in RSVPs, and QR check-in at the door, because a real club night involves people who decided to come that afternoon and want to hand you a card.
The money always reconciles. See below — this is the part that decides whether the product is trustworthy.
Interface notes
No password, ever
The member is signed in and never made an account. The link in their email is the whole of it, so there is no reset flow because there is nothing to reset.
The money is itemised, not a total
Two dinners and two raffle tickets, priced separately, then added up. A single number is the thing people ring the treasurer about.
Changing your mind is a button, not an email
Editing a reservation is self-service right up to the cutoff. Every change a member cannot make themselves becomes somebody's evening.
The hard part
Making the money add up. Always.
The obvious approach is a "paid so far" figure on each booking that you add to. It works until the first refund, and then never quite works again — a running total cannot tell you how it got there, cannot survive the same payment being recorded twice, and quietly drifts away from what the card processor thinks.
Instead, every movement of money is its own permanent line, and any balance is worked out fresh from those lines. Replay them in any order and you land on the same number.
Then the awkward realities get handled deliberately rather than by accident: refunds and cancellations happen in a defined order, overpayments are caught rather than silently absorbed, and anything from before the rule existed gets reconciled automatically.
It is unglamorous and it is the whole product. A club treasurer will forgive a plain screen. They will not forgive a number that is wrong.
Stack
| Frontend | React 18 + Vite, Wouter, TanStack Query |
|---|---|
| UI | shadcn/ui New York on Radix, Tailwind, framer-motion |
| Backend | Express + TypeScript |
| Database | PostgreSQL (Neon) + Drizzle ORM, with SQL migrations |
| Auth | Magic links for members, sessions with 2FA-grade hygiene for admins — Two audiences, two threat models, two mechanisms. |
| Payments | Stripe, plus Stripe Terminal for card-present at the door |
| Resend, with scheduled cutoff charges and comp nudges | |
| AI | OpenAI flyer parsing — drop in a flyer, get a draft event |
| Door ops | QR check-in scanning, print views for guest and seating lists |
| Distribution | An embeddable events widget for a club's own site |
Outcome
In pilot with a private social club — events, seating, dues, comps, terminal payments and door check-in all in real use.
The next step is the product: the same system generalised for other clubs as ineedtorsvp.com. The pilot club stays the proving ground, which is why the money model was built properly before the second customer, not after.