Index
Consumer App · Live Product

TeeTimeBuddy: Golf Trip Planning for Crews

A realtime planning surface that turns group-chat intent into a real plan — shared availability, trip voting, expense splitting, and crew chat tied to the trip.

Role
Founder & Builder
Product
Realtime golf trip coordination for weekend warriors and once-a-year crews
Stack
TanStack Start, React 19, Tailwind v4, shadcn, Supabase Auth, Postgres, RLS, Realtime, TypeScript, Vite, Cloudflare Workers
Architecture
10 data tables · 3 realtime tables · Row-Level Security · Supabase Realtime subscriptions
Status
Live demo at teetimebuddy.app — MVP stage focusing on pre-booking coordination
01

The Problem

Golf trips usually fail before anyone books a tee time. Availability lives in a group chat, votes are vague, and one organizer has to chase the crew until a date finally sticks. By the time everyone agrees, the best windows are gone.

The coordination layer is the hard part. Finding when 6-7 people are actually free, getting buy-in on a destination, and splitting costs fairly — all of this happens in 47-message group chats that nobody wants to scroll through.

02

The Solution

TeeTimeBuddy gives the crew one shared planning surface. Members mark availability, vote in / maybe / out on proposed trips, chat in context, and keep the current plan visible without digging through messages.

  • Shared availability grid for the crew — tap to cycle Free / Maybe / Busy across a 90-day horizon.
  • Smart trip windows — the system cross-references everyone's calendar and surfaces the best stretches.
  • Trip proposals with clear voting states — I'm in, Maybe, Out — so the captain knows exactly where consensus stands.
  • Realtime crew chat tied to the plan, not lost in a separate thread.
  • Expense tracking with automatic split calculations and settlement summaries — who owes whom, settled at the 19th.
03

Inside TeeTimeBuddy

Screens from the live demo. The Saturday Hackers crew is synthetic — no real user data.

Smart trip windows — best stretches over the next 90 days based on the whole crew's availability.
Availability grid — each crew member's Free / Maybe / Busy state across 6 weeks at a glance.
Trip voting — Bandon Dunes Weekend with 5 in, 1 maybe, 0 out. Quorum reached.
Expense tab — itemized costs, who paid what, and automatic settlement math.
Crew chat — banter on, side bets settled at the 19th. Chat stays tied to the trip context.
The Pick — unanimous green light for June 19-21. Propose this trip with one tap.
04

Architecture and Technical Decisions

TeeTimeBuddy is built on TanStack Start with React 19, using Supabase for auth, Postgres, and realtime subscriptions. The goal was a responsive, collaborative experience that feels instant even when 7 crew members are updating availability at the same time.

  • Realtime-First: Three tables (availability, chat, votes) use Supabase Realtime so updates propagate instantly across all connected clients.
  • Row-Level Security: All data is scoped by crew membership. You only see crews you belong to, and RLS policies enforce this at the database layer.
  • Smart Window Algorithm: The trip-window picker cross-references every member's availability grid to surface stretches where the most people are free — even when 6 calendars look impossible, it finds the gap.
  • Expense Settlement Math: The tab tracks who paid what, calculates per-person share, and outputs a minimal settlement graph (who owes whom, how much).
05

Product Loop

The core loop is simple: a captain creates a crew, shares an invite link, members mark their availability, the group sees the best windows, and the captain turns consensus into a proposed trip. Once quorum votes in, the trip locks and coordination shifts to logistics.

What TeeTimeBuddy Owns
  • The gap between "we should play" and "this trip is real."
  • Pre-booking coordination — availability, votes, chat, expenses.
  • Not trying to replace booking engines or on-course GPS apps.
06

Honesty Notes

TeeTimeBuddy is an independent MVP/demo product focusing purely on pre-booking coordination. It does not handle live tee-time inventory, payments, or on-course GPS. The next phase includes deployment freshness, RLS policy audits, secure invite tokens, guest responses, server-side domain workflows, observability, notifications, and shareable planning pages.

Present as a credible build demonstrating realtime coordination patterns, not a scaled commercial platform.