Anyone can ship the workout screen. We shipped the system.
The Problem
Most coaching apps ship a pretty workout UI and leave programming, chat, payments, and admin as afterthoughts. Coaches drown in DMs; purchases don't match programs; athletes get generic plans that plateau fast.
Our Answer
We built the operating system first: nineteen Laravel domains for programs, purchases, chat, nutrition, vouchers, and orders — then the Flutter athlete and coach surfaces on top. The workout screen is the tip; the system underneath is why it still works a year in.
GetStenix is not a training app with a database behind it. It is a coaching operation — programming, chat, nutrition, payments, admin — that happens to open on a phone. Athletes get one-tap sessions, set logging, rest timers, and an exercise library. Programs adapt to goal, level, equipment, and calendar, including a first-class Ramadan track; low-confidence purchase matches go to a human. Coaches run live Firestore threads with an FAQ layer. Laravel (Passport) and nineteen domains power vouchers, products, orders, and analytics so the pretty half survives contact with real users.

By the numbers
Backend Domains
App Screens
Feature Areas
What's inside
Auto-matches purchases to programs; reads the person, not a template — including Ramadan levels.
Schedule → session → set logging with demo videos, rest timer, and stopwatch — built for one-handed 6am use.
Real-time Firestore threads for athletes and coaches, with FAQ answers before a human is needed.
Assign programs, clear unmatched purchases, manage vouchers, products, orders, and analytics.
19 backend domains, 49 app screens, 18 feature areas — not a thin content app.
How we got here
Mapped coaching ops: programming, purchases, chat, admin queues
19 Laravel domains, Passport auth, purchase→program matching logic
Athlete and coach flows, Firestore chat, workout UX
Live on stores; admin queues and programming rules refined from real traffic