Case studySports & recreation · Booking
The Courtyard
A live booking app for a pickleball venue, with an admin dashboard that works like a CRM (bookings, payment receipts, courts and players in one place), plus Open Play, a court marketplace and a members' community.
- Booking app
- Admin dashboard (CRM)
- Payment receipt flow
- Real-time availability
- QA
- Project
- The CourtyardPickleball courts
- Industry
- Sports & recreation · Booking
- Location
- Davao City, Philippines
- Engagement
- Booking app and admin dashboard: design, build and QA
- Status
- Live
- Platforms
- Base44 · Email one-time-code sign-in · Bank QR payments with receipt upload

01Context
The Courtyard is a pickleball venue in Davao City with two professional-grade courts, specialty coffee and a community built around the game. I designed and built its booking app at thecourtyard.pro: players book and pay from their phones, and staff run the venue from an admin dashboard that works like a CRM.
Designing a booking app and a CRM-style admin dashboard for a real local sports venue.
02How it works
How it works
How The Courtyard works
Players book and pay on their phones; the venue runs bookings, payment receipts and courts from one admin dashboard that works like a CRM.
- Key step
- Control point
01Find a court
- Player
Opens thecourtyard.pro (or scans a QR code) and checks live availability for both courts.
- The app
Shows real-time availability, so a slot can't be double-booked.
- Venue staff
Keep court details and the schedule up to date.
- Player
02Book
- Player
Picks a court and a time, and signs in with a six-digit code sent by email. No password.
- Player
03Pay
- Player
Scans the venue's bank QR with any banking or e-wallet app, then uploads the receipt.
- Venue staff
Check the receipt in the admin dashboard and confirm the payment.
- Player
04Confirm
- Player
Finds the booking in My Bookings.
- The app
Sends the confirmation email.
- Player
05Play
- Player
Checks in and plays, or opens the court to Open Play and sends players a check-in link.
- Venue staff
Run the Open Play queue at the desk: fair teams, rotating on as courts free up.
- Player
06Plans change
- Player
Posts a paid court they can't use on Pasalo, the court marketplace; chats in the members' community.
- The app
Once a handover is confirmed, emails both players each other's contact details.
- Venue staff
Confirm Pasalo handovers: nobody may ask for more than they paid.
- Player
What staff manage in the admin dashboard
Bookings
Every reservation by court and time, in one list.
Payments
Uploaded receipts waiting to be checked and confirmed.
Courts & schedule
Court details and times, adjusted by staff.
Players
Who booked and when: the CRM side of the dashboard.
Open Play & Pasalo
The walk-in queue and court handovers between players.
Test data
Super-admin controls to test end to end without touching real bookings.
03Problem
A court-booking business depends on a schedule players can trust and staff can manage. The Courtyard needed booking and payment that work on a phone, confirmations players can rely on, and one place where staff can see every booking, confirm every payment and control the courts.
04My role
What I owned
- Booking workflows: real-time court availability, court and time selection, and My Bookings for players
- An admin dashboard that works like a CRM: bookings, payment receipts to confirm, courts, the schedule and the players behind them
- Bank QR payments with receipt upload, confirmed by staff, plus confirmation emails
- Build on Base44: booking, payment receipts, confirmation emails, admin schedule editing and passwordless email sign-in
- Open Play queues, Pasalo (a marketplace for handing over paid courts) and a members' community with chat and leaderboards
- QA on confirmations, court-time changes and loading behavior, with super-admin test-data controls
- QR-based entry points, responsive UI, loading states and brand details on the venue's own domain, thecourtyard.pro
Platforms
Base44 · Email one-time-code sign-in · Bank QR payments with receipt upload
05Approach
- 01Design around the visitReal-time availability, court details and booking built for phones; players pay by bank QR and upload the receipt in the same flow.
- 02Run the venue like a CRMOne admin dashboard for bookings, payment receipts, courts and the schedule. Staff confirm payments and adjust court times without leaving it.
- 03Build the community around the courtsOpen Play queues for walk-ins, Pasalo for handing over a court someone can't use, and a members' community with chat and leaderboards.
- 04Sign in with an email codePlayers sign in with a six-digit code sent to their email. No password to choose or forget.
- 05Test safelySuper-admin test-data controls let the team test end to end without touching real bookings.
- 06Chase what players feelLive issues reproduced and worked on: confirmation-email failures, adjusting court times, and toast and loading behavior.
06System & deliverables
Delivered
- Public booking app with real-time availability and My Bookings
- Admin dashboard: bookings, payment-receipt confirmation, courts and schedule
- Bank QR payments with receipt upload, and confirmation emails
- Open Play, the Pasalo court marketplace and a members' community
- Passwordless email sign-in
- Super-admin test-data controls
- QR-based entry points, mobile-responsive UI, loading animation and favicon
07Evidence
Screenshots from the project and scope diagrams drawn for this portfolio. Select one to open it larger.
08Results & impact
- Built a live booking app on the venue's own domain, with real-time availability, bank QR payments and confirmation emails.
- Built an admin dashboard that works like a CRM, so staff confirm payments, manage courts and control the schedule in one place.
- Extended the app beyond bookings: Open Play queues, a court marketplace (Pasalo) and a members' community.
- Structured safe testing of the whole flow with super-admin test-data controls, and worked through live issues as part of the build.
No performance numbers are shown until they can be verified and shared. This section describes what was built, structured and tested.
09Lessons
- Booking systems are trust systems. A missing confirmation email costs more than a missing feature.
- Test data needs its own controls so QA never touches real customers.