Flagship product
TeeUp
TeeUp is being designed and engineered as a two-sided golf product: a golfer mobile app for discovering courses and booking tee times, and a club dashboard for running the day — inventory, bookings, payments and on-course operations.
- Role
- I own product definition, UX, the golfer mobile application, the club dashboard, and the booking domain that sits between them.
- Timeline
- Active product
- Technology
- React Native / Expo · Next.js · TypeScript · Supabase · PostgreSQL · Row Level Security · Paystack
Areas of work
- Product strategy
- UX
- Mobile application
- Club dashboard
- Golfer accounts
- Course discovery
- Live tee-time availability
- Bookings
- Carts
- Player invitations
- Payments
- Booking management
- Cancellations
- Starter operations
- Tee sheets
- Check-ins
- Waitlists
- Reporting
- Golf course administration
- Course mapping / GPS
These are areas of work on the product. Not every capability listed here is implied to be commercially live.
01 Context
Golf clubs still run a lot of the day through fragmented tools, phone calls and paper. Golfers, meanwhile, need a reliable way to find a course, see what is actually available, and book a tee time without a back-and-forth.
02 Problem
The product problem is operational, not just presentational: availability, carts, party size, payments, invitations and starter workflows all have to stay consistent between the golfer in the app and the club on the desk.
03 My Role
My role covers the path from product definition through UX, system architecture, engineering and deployment — across the Expo golfer app, the Next.js club dashboard, and the Supabase-backed booking domain.
04 Product
TeeUp is structured as two coordinated surfaces on one domain:
- Golfer mobile application — discovery, tee times, bookings, waitlists and player invitations
- Club dashboard — tee sheets, carts, booking management, starter operations, reporting and course administration
05 Key Decisions
A shared booking domain, rather than two loosely coupled apps, keeps inventory, payments and operational state consistent. Row Level Security in Postgres is treated as part of the product boundary, not an afterthought.
06 Architecture
The current foundation is an Expo golfer client, a Next.js course dashboard, and a Supabase/PostgreSQL booking domain with Row Level Security. Payments go through Paystack.
07 Interface
The golfer phone and the club dashboard are two surfaces on the same operational model — discovery and booking on one side, tee sheets and today's play on the other. GPS hole preview sits in the same product, for when the round is underway.
08 Difficult Problems
The hard parts sit in the booking transaction: holding inventory, quoting carts and players, confirming payment, and keeping waitlists and cancellations from double-selling a tee time.
09 Outcome
TeeUp is an active product, not a retrospective with published usage figures. The work is the system itself — a booking platform that can be operated by a club and used by a golfer.
10 What's Next
Continue tightening the operational loops — starter flow, waitlists, reporting and course mapping.
Next
Fuelhaul