OTconnect
Orangetheory Fitness · 2024 - Present
OTconnect is what coaches and members use during a live Orangetheory class: the coach console, the performance board on the studio wall, and the screens on the equipment. I was a primary engineer on the 6-person team that built it to replace the previous in-studio software, with most of my work in the coach console, the studio-local data layer, and the member-facing board.
- studios live
- 1,200+
- classes a day
- ~5,000
- heart rate per member
- 1 Hz
- countries
- 3
Work project, described at the product level. Screenshots and internals stay with the company.
- C#
- .NET
- TypeScript
- Real-Time Systems
- Edge Software
- IoT
Replacing software that is already running the class
The old software could not keep up with where the product was going: new equipment, wearables, and a rollout to well over a thousand franchise locations. The replacement had to do everything the old one did on day one, because members do not experience a migration - they experience a class that works or one that does not.
That sets the bar differently from most software. A failure at 5am is not a retry queue, it is a coach standing in front of twenty people with a blank board. Every decision below comes back to protecting that first class of the day.
Why some of it lives in the studio
Bookings, members, and history belong in the cloud. The live class does not. Studio internet is whatever the franchise has, and a class cannot pause because a connection dropped halfway through a treadmill block.
So the running class is owned locally: the roster, who is on which piece of equipment, and every heart-rate reading happen in the room, and the cloud is kept in step around it. Deciding which state had to be local, and how it reconciles with the cloud when a booking changes mid-check-in, was a large share of the real design work.
What real time means in a room
Each member's heart rate arrives about once a second, for 10-20 people per class, 4-5 classes a day per studio. That adds up to roughly 5,000 classes a day across the fleet.
Real time here is measured in human terms. A member glancing at their tile needs it to be current within a second or two, and a coach needs the room to be correct more than instant. That framing kept the work on what people actually notice - stale tiles, members missing from the board, a class that will not start - rather than shaving latency nobody could see.
Invariants a coach can see
In most systems a data integrity bug is a log line. Here it is visible from across the room: two members sharing one heart-rate strap, two people assigned to the same rower, or the next class checking in on top of the one still running.
A lot of what I built was making those states impossible rather than recoverable. One primary strap per member, including loaner straps. One member per piece of equipment. Safeguards so overlapping classes cannot trample each other's live state.
Adding a second heart-rate source
Some members train with an Apple Watch instead of a chest strap, and some wear both. The goal was for a watch member to be completely unremarkable to a coach: on the roster, on the board, in the right class, with a small indicator that they are on a watch.
The interesting part was priority. When a watch and a strap are both sending for the same person, the watch wins. A simple, predictable rule beats a clever merge, because a coach has to be able to explain what the board is showing without thinking about it.
Outside the US
The first version assumed US English and imperial units. Studios in Canada and Spain needed the same class without a fork of the product, so I led the work to internationalize the in-studio stack: translations as part of the build rather than a spreadsheet handoff, French-Canadian and Spanish, and metric or imperial units that carry consistently across every screen in the studio.