NextXI

Cricket coaching runs on a coach’s eye and one look at a net session. NextXI measures the session instead.


THE PROBLEM

“Your elbow drops when you tire” is a feeling, not a number.

A young player gets told to keep the front elbow high. They can’t see their own elbow, the coach is watching at full speed with the naked eye, and neither of them can tell whether this week was better than last. And the players who get scouted are the ones a scout happened to be standing in front of.

So the product is two things. It’s a measurement tool that turns a phone clip into numbers a fourteen-year-old can act on, and it’s a scouting platform where those numbers reach coaches who were never in the room.

THE VISION STACK

Detection is the easy part. Raw keypoints jitter.

I trained custom YOLO detectors and paired them with a pose estimation model to track body keypoints through every ball. That part is well documented. The problem is what comes out. Per-frame estimates wobble by several centimeters from one frame to the next, and an elbow angle computed from wobbling joints is noise with a decimal point on it. Differentiate that to get bat speed and it’s worse than useless.

The real work was an OpenCV post-processing pipeline with Kalman filtering. It treats each joint as a body with momentum instead of a fresh guess every frame. The filtered trajectories are smooth enough to differentiate, and that’s what makes stride length, head travel, swing path, and bat-tip speed real measurements instead of numbers you can technically compute.

NextXI tracking a front-foot drive with a pose overlay
A front-foot drive at 9.00s. Elbow 146.4°, stride 1.02 m, bat tip 0.7 mph, all read off filtered trajectories rather than raw detections.
THE PLATFORM

Video analysis is a long job. The platform had to survive that.

A clip takes minutes to process, so the web app can’t sit and wait on it. I shipped a production Next.js, TypeScript, and Prisma scouting platform with role-based access and co-located server actions. It talks to the computer vision service through a Postgres-as-a-queue worker with idempotent job handling. I used Postgres instead of a dedicated broker because job state and application state need to agree, and one transactional database beats two systems that can drift apart. Idempotency matters because a worker will get killed mid-job at some point, and a retried upload can’t produce a second report.

Role-based access isn’t optional here. The users are minors. Guardians see everything their child sees, coaches are verified before they can contact anyone, and footage stays private unless the player opens it up. That shaped the schema before it shaped the UI.

250+players running video analysis
10+coaches actively using the platform
240 fpscapture rate in production
WHAT’S STILL HARD
01Monocular depth. Stride length from one camera depends on assumptions about the player’s distance and the ground plane. Prop the phone at a new angle and the answer changes.
02Ground truth. Nobody has motion-capture numbers for these players, so the metrics are consistent with each other but not validated against anything external. That’s the next thing I want to fix.
03Knowing when to refuse. When footage can’t be measured (bad angle, occlusion, poor light), the report has to say so instead of producing a confident number. Getting that boundary right matters more than any single metric.
STACK
YOLOPose estimationOpenCVKalman filteringNext.jsTypeScriptPrismaPostgreSQL