coaching that scales.
One coach, many athletes, each with their own program, diet, and history, none of it leaking across.
grow the roster, not the hours.
A coach has one scarce resource, and it is not clients: it is hours. Capacity is set by how many hours each client costs, and the only way to take on more athletes without thinning out is to compress the work that repeats and protect the work that cannot. The other half of scaling is invisible until it fails: every client must sit in their own sealed lane, because one leak across the roster is one too many.
one coach, many sealed lanes.
A coach reaches every athlete, but no athlete's lane touches another's. Each client carries their own program, diet, and history, and the wall between them lives in the database itself. Row-level security is the boundary, not a filter in app code that a single bug could slip past. Scaling a practice safely means this wall holds at one client and at five hundred.
a coaching week, hour by hour.
Take a coach carrying twenty-five clients on roughly forty working hours a week. Most of that time is not the coaching itself, it is the scaffolding around it: building and revising programs, logging nutrition, chasing updates, and the admin that never shows up in a testimonial. Templating and automation cannot compress the real check-in, and should not try. They compress everything else.
the roi of scaling well.
More clients only pay if the hours per client fall as the roster grows. Done badly, a coach trades free evenings for marginal revenue and burns out at forty clients. Done well, templating bends the cost curve: the hundredth program reuses the first, the check-in stays sharp, and capacity rises faster than effort. The same forty-hour week carries a very different practice depending on which curve you are on.
- hours / client / wk
- 1.4 hrs
- weekly hours
- 14 hrs
- monthly fee
- $250
- monthly revenue
- $2,500
- hours / client / wk
- 1.0 hr
- weekly hours
- 25 hrs
- monthly fee
- $220
- monthly revenue
- $5,500
- hours / client / wk
- 0.7 hr
- weekly hours
- 35 hrs
- monthly fee
- $190
- monthly revenue
- $9,500
Illustrative coaching economics for an online solo practice. Hours per client fall as templating absorbs the repeatable work, and fees ease slightly at scale to fill the roster. Real figures vary with niche, pricing, and how much of the work is genuinely templated. The point is the shape of the curve, not the exact dollars.
spreadsheets and dms, or trainbase.
Most coaches start with a folder of spreadsheets and a phone full of direct messages. It works at five clients and quietly breaks at twenty-five. The failure is rarely dramatic: it is the wrong macros pasted into the wrong tab, a plan sent to the wrong athlete, a check-in lost in a thread. At scale, the manual stack does not just cost time, it costs trust.
| spreadsheets + dms | trainbase | |
|---|---|---|
| data isolation | manual, by convention; one shared sheet is one leak | row-level security in the database; no client reaches another |
| time per client | rises with the roster; copy-paste scales linearly | falls with the roster; templates resolve to each client |
| error risk | high; wrong tab, wrong cell, wrong recipient | low; programs resolve from each client's own 1RMs |
| client experience | a static file and a thread of messages | their own body, today's session, their coach's last note |
| what breaks at scale | the coach; admin swallows the coaching | nothing structural; the wall holds at 5 or 500 |
the honest answers.
How many clients can one coach actually carry?
It depends entirely on hours per client, not on a magic number. A coach doing weekly bespoke programming by hand tops out around thirty to forty before quality slips. When the repeatable work is templated and automated, the same forty-hour week comfortably carries fifty or more, because the freed hours go back into the check-ins that matter.
Does templating mean every client gets the same plan?
No. A template is a starting structure, not a finished prescription. Programs are built as percentages of each client's one-rep max, so the same template resolves to different concrete weights for different athletes. The coach edits from a strong default instead of starting from a blank page every week.
How do you guarantee one client never sees another's data?
The boundary lives in the database, not in app code. Row-level security policies mean a query for one client's program physically cannot return another client's rows, even if the application above it has a bug. It is the same policy at the second client and the five-hundredth, which is what makes scaling safe rather than risky.
What stops scaling from turning into burnout?
Protecting the work that cannot be automated. Trainbase compresses program design, plan edits, nudges, and admin, and deliberately leaves the real check-in whole. Scaling well means spending the hours you get back on coaching, so the practice grows in revenue without thinning out in attention.