Recip.club
Give the request somewhere to live.
Recip.club gives reciprocal golf and dining requests between private clubs a shared workflow. A member wants to visit another club: the home club approves, the host club responds, and everyone knows what happens next. In practice, that work is often scattered across calls, email, handwritten notes, and whoever happens to be at the desk.
Status: in preview with pilot clubs in Southwest Florida; full release planned for summer 2027. Team: cofounded by Michael Hines (business, architecture, development) and a club-industry practitioner (requirements, specifications, outreach, testing).
It started with an interruption
Michael's cofounder was an assistant golf professional, and coordinating reciprocal visits followed her beyond the golf shop: calls and callbacks on her time off. As she described the process, Michael recognized a pattern from years of service operations: a request arrives, moves between people with different responsibilities, gets a decision, and needs a clear resolution.
The opportunity wasn't to put a form online. It was to give the request a place to live through the whole process, so its history and next step don't depend on reconstructing a conversation.
Two clubs, different decisions
Reciprocity isn't buying an open tee time. The member belongs to a home club, the visit involves a host club, and the relationship between them has its own rules. Recip separates the member's request from the clubs' decisions: the home club approves and routes it, the host club confirms or declines, and the member follows progress without being able to approve their own request. That separation is built into the permissions, not just the labels on the screens.
Recip works alongside a club's existing tee sheet and point of sale. It handles the coordination between clubs; it doesn't try to replace the systems a club already runs.
Ask for what matters, including flexibility
The request flow asks for what the member is trying to arrange: activity, date, time, preferred clubs, party, and special requests. Date flexibility is captured up front (one day, a day either side, a three-day window, or any day that week), so the clubs have what they need without another round of questions.
A workflow that keeps moving after the page closes
Clubs have acceptance windows, and a request may wait before a host can act. Background workflows process queued requests and send notifications on their own schedule, so whether a club hears about a request never depends on someone keeping a browser tab open. Notifications go to the staff whose job it is to act.
Shared platform, specific access
One workflow legitimately involves a member and staff from two different clubs. Access is enforced in layers: the database decides which records belong in each person's view, and the application decides which actions each person may take.
Built with
TypeScript, Next.js, and React; PostgreSQL with row-level security; background workflows for queuing and notifications.