It's a common problem for NBA coaching staffs: fine-tuning a training load for each player, correcting a shooting mechanic, figuring out how much recovery a player needs before the next game. That's a performance problem first: the win column moves on a decision made this week, while a safety outcome is much harder to pin on any single choice, often taking years and a league-wide dataset to confirm. What's measurable, directly and immediately, is whether a coach adjusted a rotation or caught a mechanical flaw before it became a habit.
There's a second reason the underlying data matters: NBA teams paid out $1.3 billion in salary to injured players during the 2025-26 season alone, based on an analysis of Spotrac's injury tracker. That money buys nothing on the court, since an injured player's contract counts against the cap whether he plays or not - for a roster already near the luxury-tax line, one bad injury during a playoff push can mean finishing it a player short with no room to sign a replacement. Get the performance signal right, and a lower injury risk tends to follow with it, even without a way to prove that link season over season.
None of this is happening in a data vacuum. NBA teams already lean on several tools to make sense of all that court data, including Hawk-Eye's multi-camera tracking system. Biocore, a biomechanical engineering consultancy and research company, built an API of its own on top of that data. But two decades of work with the NFL had already taught it a lesson: it needed something more. What NBA teams lacked was a fast way to turn that data into something a coach can easily use: a read on a player's shooting mechanics, a tactical breakdown of a broken play, or an exertion pattern worth flagging before it costs a team either way. That's the tool Biocore set out to build - something a coach could open and use directly, with no specialist needed to translate the feed for them.
Biocore wasn't choosing a partner to create the platform blind. We had already worked together for years on projects like BEAST and Mouthguard Sensor. These years of shipping products together had earned Merixstudio a specific kind of trust: a track record of finished, tested increments a client could hand straight to a sports organization. That familiarity also brought speed, since nobody had to spend the opening weeks learning how Biocore's team worked or what its data actually meant. With only four months on the clock, that trust left no time to waste on a new vendor's learning curve.
Key challenges:
The engagement opened with a four-day product design workshop built around Biocore's existing proof of concept. Across those working sessions, the two teams mapped who the platform actually served, coaches and the analysts preparing data for them, and settled on the scope for a first release, narrowed down from a broader set of ideas that had also touched on injury screening and general platform features. The workshop also flagged the risks most likely to derail a four-month timeline, competitive pressure among them, and assigned each one an owner before it closed.
Biocore's original proof of concept already covered part of the data and visualizations the final product needed. Building the full application meant expanding that analytical foundation with more data and additional ways to present it, then shaping all of it into something a coach could work with day to day. It still needed a shape better suited to daily coaching use. Comparing two shots meant jumping between separate screens, and every user, whether an admin or a head coach scouting a rival team, saw the same dense wall of data regardless of what their job actually required. Merixstudio's designers consolidated those comparisons into a single view, added a role layer so a given login surfaces only the data relevant to it, and separated the step of choosing which data to look at from the analysis itself, which had previously been tangled together. The 3D skeleton view got a similar pass: clearer color coding and a camera that follows the action, small changes that made a player's mechanics noticeably easier to track frame to frame.
.avif)
Frontend work carried its own unfamiliar territory. Rendering a fluid, accurate 3D model of a player's body from motion-capture data was new ground for the team, and so was deciding what belonged on a given chart or table - that took understanding what a biomechanics analyst was actually trying to measure before a single chart got built. Both problems pointed toward the same stack: Next.js with React 19 formed the foundation for the interface, with three.js (via its React wrapper, react-three-fiber) handling the skeleton visualization and visx covering the charts. Merixstudio proposed this combination, along with the MUI component library, specifically to keep that render- and data-heavy interface manageable inside a four-month build.
Testing inherited a different kind of complexity. Nearly everything in the platform can be filtered, layered, or compared against something else, one player against two or an event type against any other, which turns quality assurance into a combinatorics problem more than a checklist. The team's QA engineer focused first on making sure every chart, timeline, and 3D model stayed consistent with every other view after a filter changed, then spent additional effort probing the unusual combinations nobody was likely to try on purpose butsomebody eventually would.
This was a brand-new engagement, and the project also ran inside a dynamic environment: the client’s own direction kept shifting, and the plan needed room to move with it. Managing that meant separating what actually had to ship, shooting comparison and exertion-event tracking chief among the must-haves, from what would have been a good idea but could wait, and defending that line whenever a new idea threatened to expand the four-month scope. None of that would have worked without tight coordination behind it, either: with a large scope, the project ran on a fixed rhythm - weekly design reviews, two-week development sprints running alongside those reviews, a demo every two weeks so the client could react to real, working progress, and a weekly tech sync with Biocore's own engineers to keep both sides working from the same picture.
.svg)
.svg)
.avif)
.avif)
.avif)
.avif)
.svg)
.svg)