Essay · Products (live, real users)

Padel Booker

The popular courts at a members club sell out the instant the booking window opens. So I built a scheduler that fires the booking the millisecond it does.

A members club near me has a handful of padel courts and a lot of people who want them. The good slots, weekday evenings and weekend mornings, sell out within seconds of opening. Not minutes, seconds. Miss the moment the window opens and the court is gone.

The problem

The club uses a fixed forty-eight hour advance window: a slot opens exactly forty-eight hours before it starts, so the prized weekday 6pm court opens at 6pm two days earlier. The regulars who know the rule all race the same clock, precise to the second. A human cannot win that by hand; it was obviously a race a computer should be winning.

The approach

You do not need to be fast at the keyboard; you need to be precise about time. The booking is a single request, and all that matters is that it lands the moment the window opens and not before: too early is rejected, too late is too late.

It is the same problem as low-latency trading, with padel courts instead of an order book. The edge is not predicting anything; it is being first to the venue the instant it opens. You pre-position everything, warm the connection so logging in is never on the critical path, and fire the moment the market comes up. The regulars were discretionary traders clicking by hand; I built the execution system that beats them to the fill.

So the app is a precision scheduler wrapped around a booking robot. It computes when the window opens, sleeps until just before, wakes early to bring up a live authenticated session, and fires the millisecond it flips open.

The scheduling screen of the Padel Booker app. A dark interface with fields for date, sport, time and selected partners, plus a panel showing the 48-hour advance window, when it opens, and a note that the bot will log in and fire at that exact moment.

The scheduler. You pick the slot and your partners; it computes the exact second the booking window opens and arms itself to fire at that moment.

One more wrinkle: there are three courts, and the most popular is the most contested, so the robot does not commit to one. It races a small ordered list of preferences, trying the best first and falling back the instant one comes back unavailable. From the outside it looks like a single instantaneous booking; underneath it is a tight retry loop against a system everyone else is hammering at the same second.

The stack

It is a Python service: a Flask app serving a single-page front end, with the real work in background worker threads. No headless browser. The booking layer drives the reservation system directly over HTTP using a persistent requests session, parsing the per-request CSRF tokens and replaying the exact POST the site expects. Fast and lightweight, which is the whole point when your edge is milliseconds.

Each booking runs as a worker thread that warms its session early, then enters the fire loop with bounded retries and the multi-court fallback. Accounts are backed by SQLite; a member signs in with their own club credentials, never stored, only held in memory for one booking. First login grants a free trial, gated behind a simple subscription after that. It runs as a single persistent container, because the pending bookings live in memory and the process has to stay alive to fire them.

The bookings panel of the Padel Booker app. One booking shows a green 'Booked, Court 2 secured' status confirming a successful reservation; a second shows an amber 'Waiting' status with the exact time it will fire.

The bookings panel. A confirmed reservation up top; below it, a scheduled booking armed and counting down to the second the window opens.

The outcome

It works. The slots I used to lose by ten seconds I now get without setting an alarm. I put a clean sign-up flow and a small subscription in front of it, opened it to other members, and it picked up its first paying customer: someone with the same problem, happy to stop fighting the clock.

The core idea: the booking was never a speed-of-typing problem. It was a precision-of-timing problem. Once you frame it that way, the human racing the keyboard is obviously the wrong tool. A scheduler that knows exactly when the window opens and fires at that instant wins every time.

The club publishes its own rules for the online booking system. If you are curious about the advance-window mechanics it is built around, the booking regulations are here.