Ammar Mohammed
Resume
Back to work

Case study

Addis Sport Park

Full-stack facility management for a multi-activity recreation park in Addis Ababa — ticketing, bookings, QR gate access, and subscriptions.

Live · actively maintained
NestJS
Next.js
TypeScript
PostgreSQL
Prisma
Docker
Redis
MinIO
Tailwind CSS
React
Addis Sport Park public website and facility
Public marketing & booking site — the admin portal stays internal

The problem

The park runs dozens of services — football fields, pools, gym, kids' play, sand volleyball — each with its own pricing, capacity, and access rules. Before this system, cashiers tracked sales on paper, courts got double-booked, receipts could be reused at the gate, and management had no view into peak hours or revenue. Changing a price meant reprinting sheets.

My role

I work on this as a frontend-heavy fullstack developer on a small development team.

  • Public website — the user-facing marketing and booking site: service catalog, self-service booking requests, memberships, internationalization, motion, interactive master-plan map
  • Admin portal — staff operations UI: walk-in cashier flows, booking workflows, pricing, permission-gated screens, subscriptions, reporting
  • Training, QA & feedback loops — onboard park employees on the platform, run QA, and turn field feedback into shipped fixes
  • Monitoring — keep an eye on production health and follow up on issues as they surface

The broader platform also includes gate entry for paid access, sitting alongside the public site and admin portal on a shared backend.

Architecture

Three client surfaces talk to one backend API. The diagram stays at that level — no infra internals.

System architecture

System architecture. Flow: Public website → Backend API; Admin portal → Backend API; Gate entry → Backend API.

The hard problems

Recurring bookings that stay maintainable. Long-running weekly reservations (e.g. every Tuesday evening for months) need real-time availability without turning into an unmanageable mess of duplicated records. We designed the booking model so patterns stay lean and availability is checked carefully against hours, existing bookings, and admin blocks.

Pricing that can change with the business. Peak evenings, weekend overrides, and stacked adjustments had to be expressible without building a full rules engine. Priority ordering plus a small set of adjustment types kept it flexible for the park and still understandable for staff.

Booking that fits how people actually pay. Online requests had to work with local payment habits — not assume instant card checkout — while walk-in visitors could still be handled quickly at the desk without slowing the line.

Status

Live in production — actively managing daily park operations.

Visit live site