Player
Student, faculty, staff or alumni
- Goal
- Get a slot and play, without chasing anyone.
- Worry
- Not knowing the rules, or losing a slot to a team that didn’t turn up.
- Design response
- Rules shown up front, a four-step mobile flow and a QR pass.
01 — The problem
Hundreds of students, faculty and staff share one padel court, and everyone wants the same few hours. I designed a booking system that makes access fair by rule: who can book, how often, and with whom. Then I built it and shipped it.
45 minslots, 15 minutes apart
4 playersper booking, all from the university
2 bookingsper 30-day window
1 QR passfor each approved player
610registered users
222bookings made
121approved bookings
79matches played in the last 30 days
02 — The process
From a problem to production
- 1Identify the problemOne court, hundreds of people and the same few popular hours. Without rules, access goes to whoever asks first.
- 2One conversationIt began with a simple idea: a booking system where the rules are assigned up front, not argued over later.
- 3Policies firstSlot length, booking limits, team size, who plays with whom and approval were agreed as rules before any screen was drawn.
- 4Low-fidelity screensI sketched the flow as low-fidelity screens, mobile first, for players, admins and court staff.
- 5Vibe-coding with CodexI described each screen and rule to Codex and iterated on the result, working in a TypeScript monorepo with a typed API.
- 6Shipped to productionMicrosoft sign-in, email, QR passes, an admin area and live monitoring, running on Linux behind nginx.
03 — Design system
Calm operations, a confident court
A court booking is a small decision made quickly, so the interface has to be obvious. Warm neutrals keep operations calm, plum carries the university identity, and gold marks the court experience. Players and admins share one system, so a slot looks and behaves the same everywhere.
Colour
Brand
Plum, primary
#512047Plum hover
#6A2F60Gold, accent
#BB852AWarm white
#FBF8F5Ink
#1B1319Line
#EBE5DFMuted
#7A7177Gold soft
#FFF6E5Status and roles
Green
#197347Green soft
#E8F7EEBlue
#1769AABlue soft
#EBF5FFOrange
#B86113Orange soft
#FFF3E8Red
#C93636Red soft
#FFF0F0Plum is reserved for the next meaningful action and selected states. Destructive actions stay red and visibly apart.
Typography and spacing
Space Grotesk and Inter
Book the court. Make it count.
Section heading, 27px
Body text uses Inter at 15px with a 1.5 line height. Muted copy supports, and plum is kept for actions, navigation and selected states.
4px8px12px16px24px32px48px
Components
Actions and fields
Continue bookingView rulesCancelReject booking
Roles
StudentFacultyStaffAlumni
Booking status
PendingApprovedRejected
Slots and notices
5:00 – 5:45 PMAvailable
6:00 – 6:45 PMSelected
7:00 – 7:45 PMUnavailable
ⓘ
Community booking rulesFaculty, Staff and Alumni may book together. Students book with Students.
⚑
Fair accessTwo pending or approved bookings are allowed within the 30-day period.
✓
Team completeAll four players are added. Continue to review.
Principles
- Clarity firstDates, time, availability and quota sit beside the decision being made.
- One strong actionPlum marks the next meaningful step. Destructive actions are visibly separate.
- Accessible by defaultStrong contrast, 44px touch targets and clearly visible keyboard focus.
- Unavailable is explainedBlocked and closed slots stay visible, struck through, so no rule is hidden.
- Same pattern at every widthProgress, choice, then confirmation, on a phone and on a desktop.
- Rules in plain languageEvery limit is stated where it applies, then accepted once before booking.
03 — Roles
Four roles, one court
Admin
Runs bookings and the calendar
- Goal
- Keep access fair and the schedule accurate.
- Worry
- Pending requests piling up, or double-booked slots.
- Design response
- An approvals queue, plus tools for bookings, slots, calendar and pre-booking.
Court staff
On site, on the day
- Goal
- Know who is meant to be on court right now.
- Worry
- Checking people in by hand, on a phone, in the sun.
- Design response
- Live monitoring and QR check-in.
Management
Decides how the court is used
- Goal
- See whether the court is used fairly and fully.
- Worry
- Decisions made on anecdotes.
- Design response
- Reports on matches, players, busy slots and community mix.
Who plays with whom
StudentFacultyStaffAlumni
Faculty, staff and alumni may book together. Students book with students. The rule is checked while the team is being added, so a booking never fails at the last step.
What each role can do
| Capability | Player | Court staff | Admin | Management |
|---|---|---|---|---|
| Book a slot and add a team | ✓ | |||
| Confirm a teammate invite by email | ✓ | |||
| Approve or reject bookings | ✓ | |||
| Manage bookings, slots, calendar and pre-booking | ✓ | |||
| Scan QR passes at check-in | ✓ | ✓ | ||
| Live monitoring of the court | ✓ | ✓ | ||
| See reports on usage | ✓ | ✓ | ||
| Manage users, audit log and settings | ✓ |
03 — Journey
Mobile first, then the admin desk
The front door
The public page explains the rules before anyone signs in: 45-minute slots, a two-booking cap per 30 days, one university login, and playing hours for students, faculty and staff.
Booking, on a phone
Step 01
Pick a slot
Fixed 45-minute slots with 15-minute gaps. The date strip labels Today and 2nd Sat, closed Sundays stay visible, and passed slots are greyed.
Step 02
See the choice
Selecting a slot raises a summary card with the court, the time and spots remaining, and one Continue button.
Step 03
Add the team
Every slot needs exactly four players, found by searching university people. Search locks once the team is complete, and says why.
Step 04
Review and accept
Booking details, the team, and a plain-language consent, with the 30-day booking count in view (2 of 2 used).
Step 05
Read the rules
Fair Access, Rules and Regulations open as a sheet in ten short sections, with a policy version, and one clear accept button.
Step 06
Submitted
Teammates confirm by email, admins review, and each approved player gets their own QR booking pass.
The admin desk, on a desktop
Admins start from what needs a decision: pending approvals, today’s bookings and blocked slots.
Management sees how the court is used: played matches, popular slots and weekdays, and participation by community.
Everything in the admin area
DashboardPending approvals, today’s bookings and user mix at a glance.
ApprovalsReview a booking once all four players have accepted.
All bookingsSearch and manage every booking in one list.
Check-inScan player QR passes at the court.
MonitoringA live view for admins and court staff.
Blocked slotsClose slots for maintenance or events.
Users and audit logWho can do what, and a record of what changed.
SettingsThe booking rules, held in one place.
04 — How it’s built
One TypeScript monorepo
The whole app is TypeScript with pnpm. The API is described once in OpenAPI, and the typed client and validation schemas for the frontend are generated from it, so screens and server cannot drift apart.
FrontendReact, Vite, Tailwind CSSReact Query for data, Clerk React for sessions.
BackendExpress 5 APIBundled with esbuild.
DatabasePostgreSQLDrizzle ORM for typed queries.
Sign-inMicrosoft Entra IDOAuth, turned into Clerk sessions and tokens.
API contractOpenAPIOrval generates the React Query client and Zod schemas.
Email and directoryMicrosoft GraphTeammate lookup and confirmation emails.
QR passesGenerated locallyCreated with the qrcode library, one per player.
HostingLinux on EC2nginx serves the frontend and proxies to the API service.