DanceFit
Multi-tenant SaaS for dance studios — members, instructors, studio admins and a platform super-admin on one Next.js front end and one FastAPI back end.

What it is
A ground-up rebuild of a dance studio’s management system as a multi-tenant platform: every studio is a tenant with its own centres, instructors, members and money, and one super-admin runs the platform above them. It replaces a Firebase-backed original with something that can onboard the next studio without a new deployment.
What I built
Four role-specific portals in Next.js. Members see a timetable, book classes, check in, manage packages and plans, earn referrals and gamified challenges, and leave reviews. Instructors get their schedule, availability, earnings and reviews. Studio admins run centres, classes, customers, packages, events, expenses, cash collections and announcements, with attendance, revenue and demand-heatmap reports on Recharts. Super-admins onboard clients, invite admins and read the audit log.
Behind it, a FastAPI back end on SQLAlchemy 2 and PostgreSQL with Alembic migrations — 35 routers covering bookings, subscriptions, payments, a wallet, promo codes, notifications and uploads — with JWT auth and role-based access on every route. Data fetching on the front end runs through TanStack Query with Zustand for auth and the super-admin’s client switcher.
The part that matters
Tenant isolation is not left to each router remembering to filter. A per-request context carries the acting user’s tenant, and a session-level SQLAlchemy listener injects the tenant filter into every query against a tenant-scoped model automatically. A forgotten filter excludes rows rather than leaking another studio’s data — and a test suite proves it does, rather than assuming the code compiles.