Trainr — Two-Sided Fitness Marketplace App

Trainers request a payout from their settled balance. An operator approves or rejects it in the console, then releases it with a bank transfer, PayPal or cash reference recorded; a Stripe Connect transfer path is built for when trainers' Stripe accounts are connected. A release that fails marks the payout failed instead of losing it.

• A peer's typing used to re-render the whole 1,500-line chat screen. The typing indicator now subscribes to its own state.
• The chat list re-rendered on any of twenty-plus socket event types; its selector now reads nine fields.
• Removing a listener with .off(event) and no handler was removing that event's listeners across the whole app. Handlers are now stored and removed one by one.

A member removed from a group keeps the conversation up to that point, read-only.

A program is linear or cycling. A cycling program repeats a cycle of 1 to 14 days, up to 90 days in all (the limits the trainer app enforces), and each client enrols on their own start date; the server works out which day of the cycle they are on, and logs from earlier cycles stay in their history. Each exercise carries target sets, reps, weight and rest. Clients follow a session step by step, with a rest timer set from the trainer's rest target, or log it by hand. Every set records actual reps, weight, rest and effort (RPE 1–10) against the targets, and the trainer replies on the log.

The app ships a system catalogue of 250 exercises and 100 meals as versioned seed files. Trainers clone what they need into their own library and edit it; a batch clone never stops on a name clash, it adds a suffix.

Trainers build diet programs from their meals, with calories, protein, carbs and fats. Clients log each day, and trainers answer with written nutritional adjustments on the log.

Each package can carry a check-in form that repeats daily, weekly or monthly. The trainer switches on the fields they want from thirteen: body weight, measurements, energy, sleep quality, sleep hours, stress, mood, motivation, soreness, nutrition, hydration, notes and photos. Clients who buy the package are added automatically, the server tracks each client's next due date, and the client's home screen flags an overdue check-in. The trainer's home screen counts check-ins waiting for feedback.

Workout sessions and individual classes once handled dates differently, one in UTC and one in local time, and classes could land on the wrong day. Every date-sensitive path (logs, bookings, check-ins, schedules) now uses UTC days.

On the Explore tab the client picks a centre point, saved or custom, and a radius of 5, 10, 25 or 50 km, or Any. A switch decides what counts as near: the trainer's own location, or the nearest place they actually train clients across their services, sessions and classes. Results come back sorted by distance, and each carries the distance and the kind of place it was measured to, so the app can say a trainer is 2.3 km away from one of their sessions rather than just 2.3 km away. The result cards don't display it yet. Trainers with no public location, online-only or private, are left out unless the client turns on "include online trainers"; they then follow the nearby list in alphabetical order.

With a location set, the server scores the whole trainer list before paging, because otherwise page one would not hold the nearest trainers. It fetches the locations of every trainer's sessions, services and classes in three grouped queries, not three per trainer, computes the haversine distance from the centre to each candidate point, keeps each trainer's nearest, filters by radius, sorts and then pages the merged list. Without a location, the cheap paged query runs as before.

MongoDB's $nearSphere needs GeoJSON points with a 2dsphere index. Trainr's coordinates are stored as latitude and longitude fields on five models, and moving them means a backfill across all of them. While the trainer list is small enough to score in memory, we shipped haversine and wrote down the next step: a GeoJSON point beside each location, filled in as records are saved, a 2dsphere index and $geoNear.

A development script spreads test trainers across Dubai neighbourhoods, including Downtown, Dubai Marina, Jumeirah, Business Bay, Al Barsha, Deira and JBR, between 0 and about 25 km from Downtown Dubai, so each radius chip had real differences to sort.

On 27 July 2026 Trainr shared a source-level review with 27 claims in four severity bands. We checked every claim at the exact file and line it cited and answered each with a verdict and a time to close; none was dismissed without a code-level check. We also reported a defect the review had missed: account-deletion text that cited Indian tax law and INR retention periods in a UAE product. Two items were new features rather than defects, push notifications and UAE VAT, and for VAT we listed the decisions needed first: tax-inclusive or exclusive prices, the 5% rate, trainers above and below the AED 375,000 registration threshold, and TRN collection.

On 13 August 2026 the platform passed to Trainr's incoming developer with a written record of every system's state, the open items and whose court each sits in.