MyBody
The API behind a platform where fitness coaches sell programmes and members follow workouts and nutrition plans.
- Role
- Backend developer
- Type
- Client product
- Period
- Oct 2025 – present
- Link
- mybodyapp.ir
In active development.
The problem
The client is a fitness coach who wanted to run online coaching on his own platform. Workout plans, meal plans, progress check-ins and payments for many members are hard to manage across separate tools.
The goal was one platform where members buy a plan, follow their weekly schedule, log what they did, and talk to their coach. Coaches need to manage clients and see their earnings.
My role
Backend developer. I designed and built the API on my own, from the first commit in October 2025 until now, about 255 commits.
Stack
NestJS 11
TypeScript
Prisma 7 (pg adapter)
PostgreSQL
Socket.IO
S3-compatible storage
Zarinpal
JWT + SMS OTP
Swagger / OpenAPI
Pino
Jest + Supertest
Docker Compose
Husky
Architecture
Member & coach appsREST + JWTNestJS APIPostgreSQL / Prisma · S3 media · Zarinpal
Member & coach appsSocket.IOChat gatewayPostgreSQL / Prisma
What I built
- A domain model with 52 Prisma models across more than 30 NestJS modules: members, coaches, plans and plan templates, workout sessions/sets/completions, week schedules, nutrition programmes, foods and meal logs, progress measurements, orders, wallets and bank accounts.
- Payments and money flow: checkout through Zarinpal, coach wallets with transactions, and a monthly income/withdrawal chart for coaches.
- Promotion codes, written spec-first: percentage or fixed discounts, expiry, usage caps, one use per member, and deletion only when a code is unused.
- Real-time coach–member chat over a Socket.IO namespace, with cursor-paginated history over REST.
- Media uploads to S3-compatible storage, Helmet, structured rolling logs, and Swagger docs for the frontend.
- About 50 unit test files and an e2e setup.
Result
- The API is under active development and is moving toward launch.
- I wrote payment-related features, such as promotion codes, as short specs before coding them. Each spec spells out edge cases, for example what happens when someone tries to delete a code that has already been used.
