Case study 02 Sports booking marketplace goodbookies.co.in

Good Bookies

GOODBOOKIES GOODBOOKIES

A production marketplace where players discover venues, see live availability, reserve an individual spot or an entire turf, split the cost, and pay securely. Venue partners get a self-service dashboard for inventory, pricing, bookings, analytics, and payouts.

Role
Product & full-stack engineering
Type
Production two-sided marketplace
Core stack
TanStack Start · React 19 · TypeScript
Data & payments
Supabase · MySQL · Razorpay
Good Bookies landing page: book the pitch, play the match
01

Interface

02

The booking engine

Booking is not a calendar form. Availability, capacity, pricing, payment, and abandoned checkouts all have to agree on the same time window. Good Bookies keeps that flow server-authoritative from the first tap to the confirmed slot.

  1. 01

    Choose a window

    Two taps define a start and an exclusive end time. Every slot is stored as minutes from midnight, supporting both 30- and 60-minute venues.

  2. 02

    Resolve the price

    Date override, day rule, peak surcharge, duration discount, coupon, and individual-vs-full-turf split resolve in one shared pricing engine.

  3. 03

    Hold inventory

    A pending booking locks the window for 15 minutes. Stale holds expire whenever availability is read, so abandoned checkout never blocks play.

  4. 04

    Verify payment

    Razorpay creates the order, but only a server-side signature check confirms the booking. Dismissal or failure releases the hold explicitly.

Four half-hour slots selected, with the payment portal totalling the booking
08 The slot board and checkout read the same availability and pricing state
Half-hour slot grid on a phone
09Same board, phone width
03

Architecture

Good Bookies system architecture: a React client talks to a Node application host, which owns Postgres, MySQL media stores and RazorpayclientReact 19 + TanStack StartSSR · routing · TanStack Queryapplication hostHostinger Node.jstyped server fns · mobile API · mediatransactional truthSupabase PostgreSQLusers · venues · bookings · lobbiesbinary mediaHostinger MySQLavatar and venue-media blobspaymentsRazorpayorders · signatures · refunds
The browser never touches a database. One Node host owns SSR, the typed server functions and the mobile API, and fans out to Postgres for transactional truth, MySQL for binary media and Razorpay for money.
04

Engineering decisions

05

Stack

Good Bookies / Live product

Book the pitch.
Play the match.

Next case study TrialMatch