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
- Database tables
- 32
- API endpoints
- 201
- Admin screens
- 22
Table definitions in shared/schema.ts. Counted in the repository on 8 August 2026.
Express route registrations. Counted in the repository on 8 August 2026.
Admin pages including 4 print views. Counted in the repository on 8 August 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.
The hard part
Making the ledger the truth.
The naive design puts an "amount paid" field on the reservation and adds to it. It works until the first refund, and then it never really works again — because the field is a running total, and a running total cannot answer "how did we get here", cannot survive a webhook arriving twice, and quietly disagrees with the payment processor forever after.
Instead every movement of money is an immutable row, and any reservation's balance is recomputed from those rows rather than stored. That makes the recompute idempotent by construction: replay every event in any order and you land on the same number.
Then the awkward realities get handled explicitly rather than emergently — refunds and voids have a defined ordering, overpayments are guarded rather than silently absorbed, and a reconciler runs at startup to backfill anything that predates the rule.
This is unglamorous and it is the whole product. A club treasurer will forgive a plain interface. 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.