Build or Buy: Should You Build Your Own Performance Tool?
AI coding agents made building cheap. Before building a performance tool, audit what your platform already does, who maintains the result, and which part is genuinely missing.
In this article 7 sections
Before building a performance tool, establish what your current platform already does, which part is genuinely missing, and who maintains the result in February. AI coding agents lowered the cost of writing software. They did not lower the cost of owning it. The audit comes first.
A testing session ends. The force plate software exports a CSV with dozens of columns, several trials per athlete, two spellings of one athlete’s name, and at least one mis-triggered jump. Someone spends the afternoon in a spreadsheet picking trials, rebuilding last block’s chart, and retyping the interesting names into a message for the head coach.
Until recently, a practitioner who wanted that afternoon back had one option: buy something. Now there is a second one. Open a coding agent, point it at the export, describe the pipeline, and have working code before the athletes have left the building.
That is a real change in what a performance department can do for itself. It is also the reason the first question has moved. When building was expensive, the market filtered bad ideas for you. It does not anymore.
What I scoped, and what the audit found
I specified a tool for exactly the problem above. Five stages: read the export, clean the bad trials, build a longitudinal store, chart it, and write the message a coach reads. Column mappings so it would accept any vendor’s file. Tests so the numbers could not drift between runs.
Then I checked what already existed. Three findings, in the order they mattered.
The platform already does the middle. VALD Hub ships a Timeline view for tracking longitudinal change, customizable group monitoring and benchmarking dashboards, and limb symmetry metrics. It also ships Norms, age- and sex-matched normative data drawn from millions of data points, rendered directly into the athlete profile across ForceDecks, NordBord, ForceFrame, DynaMo and HumanTrak.
My version would have produced a chart showing an athlete’s change against their own baseline. Theirs shows the same change plus where that athlete sits against their age and sex. I cannot reproduce that. Nobody outside the company can.
The integration gap was narrower than I assumed. I expected to find the real opening in unifying sources. VALD includes its integrations free with an active subscription and connects to Smartabase across ForceDecks, NordBord, ForceFrame, SmartSpeed and DynaMo. Smartabase in turn connects Catapult, Hawkin Dynamics, GymAware, Whoop and Oura. The unification problem is somebody’s shipping product, sold to the departments most likely to have the problem.
The layer below was already occupied. For anyone working from raw force-time data rather than a vendor’s computed metrics, the forceplate R package segments raw traces into trials with filtering and baseline correction, and JumpMetrics computes vertical jump metrics in Python with full test coverage on its analysis algorithms. Both are free and published.
So four of my five stages were solved, and solved better than I would have solved them. I stopped.
Does the platform you already pay for do this?
This sounds obvious. It is routinely skipped, because the honest answer requires opening documentation for a product you believe you already understand.
Most practitioners know their platform through the three screens they use weekly. Feature sets move. A capability that was genuinely missing when your department bought in two seasons ago may have shipped since, and it may be sitting behind a tab nobody opened.
Before scoping anything, read the release notes back a year and name the specific screen that does not exist. If you cannot point at the absence, you are not ready to build.
Is the gap actually their moat?
Some gaps stay open because the vendor has not gotten to them. Others stay open because closing them requires something you cannot obtain.
Normative data is the clearest example in this field. A reference distribution is only as good as the population behind it, and that population accumulates from every customer over years. A department building its own comparison has its own athletes and nothing else. That is a fine baseline and a poor norm.
Ask what the missing feature would require. If the answer is proprietary scale, buy it. If the answer is knowledge of your own staff’s decision rules, that is a different situation, and it is the one worth your time.
Who maintains it in February?
Cost of building is now measured in hours. Cost of owning is measured in seasons.
A tool that runs unattended through preseason will still break. The vendor renames a column in an export. Somebody upgrades Python. A new device arrives. The question is not whether that happens, it is who fixes it during a competitive week, and whether that person is still on staff.
This is where department-built software usually dies. Not at the build. At the first February where the one person who understood it is busy, and the tool quietly stops being trusted. A coding agent does not solve that, because the agent does not know your build exists until someone opens the repository and asks.
If the honest answer is that maintenance falls to one person with no backup, build something small enough that its failure is survivable. The companion piece on evaluating performance technology applies the same staff-time question to purchased tools.
What survived the audit
One stage. The last one.
The platforms aggregate well and display well. What they do not do is produce the short, decision-ready message that reaches a head coach who is never going to open a dashboard. That gap is documented rather than anecdotal. The analytics-practice gap literature names the barriers as limited actionability, weak contextual interpretation, fragmented information and low usability, and names the bridging factors as context integration, data synthesis, coach-analyst communication and decision-oriented metrics. A 2024 scoping review of coach and support staff monitoring perspectives reports the same pattern from the practitioner side.
Every one of those bridging factors describes the handoff between the data and the conversation. None of them describes a chart.
I wrote about that last mile separately in the morning scramble, so I will not repeat the argument here. The relevant point for a build decision is narrower: the surviving gap was the only one that required knowing my own staff’s rules rather than owning a dataset.
Where a coding agent actually belongs
If four stages are bought and one is built, the agent’s job becomes specific, and it is worth being precise about the division of labor.
The agent writes the code that reads your data. Every vendor export is slightly different, versions drift, and the mapping between their column names and your metric names is exactly the sort of fiddly, one-off translation an agent handles well. Give it the file header, have it write a mapping, have it check that mapping against the real file, and let it iterate on the error message until the file loads.
The code does the arithmetic. Thresholds, baselines, change against typical variation. Written once, in plain code, reviewed by whoever owns the decision. Identical on Tuesday and identical the following Tuesday.
Tests hold the line between the two. The point of a test here is not software hygiene. It is that a number in a coach’s message can be traced to a row in an export, and that the tracing still works after somebody changes something. In the readiness concept I built on synthetic data, this is enforced directly: every number in the generated narration is checked against the engine that computed it, and a mismatch falls back to a fixed template.
The pattern generalizes past force plates. Ask an agent to interpret your data and you get a different answer every run, with no audit trail. Ask it to write the code that interprets your data and you get something a colleague can read, argue with, and correct.
A starting point for your next staff meeting
Take the tool your department is currently talking about building, and complete five sentences before anyone writes code.
- The screen that does not exist in our current platform is…
- I confirmed that by…
- Closing this gap requires knowledge we have, specifically…
- In February, the person who fixes it is…
- If that person is unavailable for two weeks, what breaks is…
If sentence two is “I assumed,” stop and read the documentation. If sentence three describes data you would need to collect from other organizations, buy instead. If sentence five describes something a coach depends on, build a smaller version.
The useful outcome of this exercise is often a decision not to build. That is a result, and it is cheaper than the alternative. The tool I scoped for this article does not exist, and the audit that killed it took an afternoon.
Evidence note: Platform capability claims are drawn from VALD’s published product and support documentation as of September 2026, not from an audit of a live tenant. Feature sets change. Verify against your own account before making a build decision. The open-source packages cited were assessed from their published documentation and repositories. The five-sentence exercise is an editorial recommendation, not a tested protocol.