Sportefy — Sports Venue Booking & Matchmaking

The Brief

Book venues, find matches, pay.

Players book courts, join matches and pay from a consumer app; venue operators and platform staff run everything from an admin dashboard — all on one versioned API that never breaks the mixed-version mobile install base.

Consumer Flutter app — booking, slots, QR check-in & wallet, offline-first with request replay

Realtime matchmaking & match chat — Supabase Realtime + Postgres row-level security

Next.js admin dashboard over a versioned /v1 API, one shared RBAC matrix (5 platform roles + venue-scoped staff)

Payments domain — pluggable gateway adapter (Paymob), wallet / credits ledger, promo codes, PDF booking confirmations

Architecture & Stack

Two clients, one versioned contract.

ClientsFlutter + Next.js admin

→

/v1 RESTOpenAPI gates

→

NestJS · CQRSDomain core

→

Prisma · PostgresData

→

SupabaseRealtime · RLS

Stack

Mobile

Flutter 3 · BLoC

Admin

Next.jsReactTailwind

Backend

NestJS 11Prisma 7PostgreSQL

Realtime · Pay

Supabase Realtime · RLSPaymob

Key Decisions

01Monorepo — NestJS backend & Next.js admin share one typed contract & RBAC package

02Additive-only /v1 contract + server-driven version gating — zero breaking releases across a mixed-version install base

03OpenAPI drift gates enforced in CI

Walkthrough

Across app and dashboard.

Consumer App · Flutter

Venue booking & slots

Match chat — Supabase Realtime

QR check-in

Admin Dashboard · Web

Ops dashboard & analytics

Venue & booking management

Screens shown are representative recreations of the product UI — the production app is live on the App Store & Play Store.

~70API modules

150+/v1 endpoints

437Flutter tests

Live on the App Store and Play Store with a Next.js ops dashboard behind it — shipping continuously with zero breaking releases across a mixed-version mobile install base.

Book venues, find matches, pay.

Two clients, one versioned contract.

Across app and dashboard.

ETG — Enforcement-First Field-Service OS