Your athletes report an RPE. Barset checks it against the bar. Velocity-loss analysis of squat, bench, and deadlift check-in videos flags under- and over-reported sets, so you can review a whole roster from ordinary phone footage in minutes. No sensors. No guesswork. Every number comes from bar speed measured directly from the video.
Barset started from a boring observation. A remote coach gets thirty check-in videos a week, opens all thirty, and twenty-eight of them are fine. The two that matter, like the set an athlete called an 8 that was obviously a 10, are buried somewhere in the middle, and the only way to find them is to watch everything.
RPE is the number the whole program runs on, and it's self-reported. Athletes sandbag. Athletes overcall. Neither is dishonesty, perception just drifts once the block gets heavy. But a wrong RPE corrupts every load decision that comes after it.
So Barset tracks the barbell plate through the video, measures how much bar speed the athlete loses across the set, and compares that against what they reported. The under-reported sets float to the top of the queue.
The build changed shape twice, both times by cutting something.
First, I pulled out absolute velocity. The engine can convert bar speed into m/s using the plate radius, and it looked great. Precise numbers, real units. It was also unvalidated: camera angle, plate size and detection quality all move that figure and none of it gets checked. A confident wrong number is worse than an honest rough one, so m/s is a secondary column now and the RPE band runs on velocity loss only.
Second, I pulled grinding out of the RPE calculation. Detecting the mid-rep stall works fine. Telling a real grind apart from a normal lockout slowdown does not, at least not yet. So it shows up as evidence and doesn't move the number.
There's no ML model and no LLM anywhere in it. Every figure a coach sees traces back to bar movement you can watch in the annotated video, and the coach can override any of it. The override gets stored as data rather than treated as a correction.
I'd like feedback from coaches most of all: does the flagging match what you'd have caught yourself?
Hey ProductHunt 👋
Barset started from a boring observation. A remote coach gets thirty check-in videos a week, opens all thirty, and twenty-eight of them are fine. The two that matter, like the set an athlete called an 8 that was obviously a 10, are buried somewhere in the middle, and the only way to find them is to watch everything.
RPE is the number the whole program runs on, and it's self-reported. Athletes sandbag. Athletes overcall. Neither is dishonesty, perception just drifts once the block gets heavy. But a wrong RPE corrupts every load decision that comes after it.
So Barset tracks the barbell plate through the video, measures how much bar speed the athlete loses across the set, and compares that against what they reported. The under-reported sets float to the top of the queue.
The build changed shape twice, both times by cutting something.
First, I pulled out absolute velocity. The engine can convert bar speed into m/s using the plate radius, and it looked great. Precise numbers, real units. It was also unvalidated: camera angle, plate size and detection quality all move that figure and none of it gets checked. A confident wrong number is worse than an honest rough one, so m/s is a secondary column now and the RPE band runs on velocity loss only.
Second, I pulled grinding out of the RPE calculation. Detecting the mid-rep stall works fine. Telling a real grind apart from a normal lockout slowdown does not, at least not yet. So it shows up as evidence and doesn't move the number.
There's no ML model and no LLM anywhere in it. Every figure a coach sees traces back to bar movement you can watch in the annotated video, and the coach can override any of it. The override gets stored as data rather than treated as a correction.
I'd like feedback from coaches most of all: does the flagging match what you'd have caught yourself?