Athlete Performance and Training Load Software: Why Your Readiness Picture Is Split Across Five Vendors

Why the readiness picture never assembles itself

It is 7:10am and the head of performance is trying to answer one question before the coach walks in: can the left back train fully today. The GPS session from yesterday is in the Catapult portal. The morning wellness responses are in a form that exports to a spreadsheet. The force plate jump from Monday is in a separate platform with its own athlete list. The physio's note about the hamstring is in the medical system that the performance staff cannot see, correctly, because it is medical data. The gym session is on a whiteboard. The answer exists. It exists in five places, and assembling it takes twenty minutes that nobody has at 7:10am.

So the staff builds a spreadsheet. Every club has this spreadsheet. It pulls exports from three or four systems, applies the club's own thresholds, and produces a traffic light per athlete. It is maintained by one sport scientist, it breaks whenever a vendor changes an export column, and it contains the club's entire analysis methodology in formulas nobody else understands.

That spreadsheet is the actual product. The hardware vendors sell measurement. Nobody sells the club's judgement about what those measurements mean for this athlete at this point in the season, because that judgement is the thing performance staff are hired for and the thing they take with them when they leave. Player availability is the biggest controllable input to results and to squad value, and the system that governs it is a workbook on one laptop.

Problem 1: the athlete identity is the join, and no vendor owns it

Every platform has its own athlete list, its own IDs, and its own idea of a session. The GPS system knows a training session by timestamp and drill period. The force plate system knows a test by date. The medical system knows an athlete by a clinical record number. The gym app knows them by an email address they last updated two years ago. When a player arrives on loan in January, somebody creates them five times.

Catapult, Kitman Labs, Smartabase and Teamworks all offer exports and API access, so the data is not locked in the crude sense. What is missing is the layer above them: one athlete identity, one session context, one timeline. Without that, every piece of analysis starts with a manual reconciliation, and the reconciliation is where the errors live.

What a custom build does: own the identity and the calendar. One athlete record with vendor identifiers mapped underneath it, so a new hardware supplier is a mapping change rather than a migration. One session object that carries the coach's plan, meaning the drill, the intended intensity and the phase of the week, because a 900 metre high speed running total means something entirely different in a rondo than in a match simulation. Raw data lands in your own store first and stays there, which quietly solves the exit problem: when you change GPS suppliers, and you will, your history stays yours in a form you can still analyse.

Problem 2: the analysis model is your edge, and the platform imposes its own

Vendor platforms ship with proprietary composite metrics and default thresholds. They are computed a particular way, and you generally cannot see the arithmetic or change it. Acute to chronic workload ratio is offered as a standard view even though its usefulness is actively argued over in sports science, and the argument matters, because a flag that fires wrongly twice a week gets ignored within a month.

Your staff has a view. It is usually specific and hard-won: that this striker's meaningful signal is high speed running exposure relative to his own rolling baseline rather than any squad norm, that a centre back returning from a calf issue needs deceleration volume capped rather than total distance, that the questionnaire only predicts anything for about a third of the squad and you know which third. That view is the intellectual property. It cannot be a configuration option in someone else's product.

What a custom build does: make the model explicit, editable and versioned. Individual baselines rather than squad averages, position-specific weightings, thresholds your staff sets and can change on a Tuesday without raising a support ticket. Flags carry their reason: this athlete is amber because deceleration count is 40 percent above his four week baseline while sleep duration has dropped for three nights, not because a red dot appeared. And every threshold change is dated, so when you review a soft tissue injury in April you can see exactly what the system was saying in February and whether anyone acted on it.

Problem 3: coaches do not open dashboards, so delivery is the feature

A performance platform that requires a coach to log in, choose a report and interpret a chart will be used for three weeks. This is not a failure of coaches. It is a failure of product design applied to a person who has forty minutes between arriving and taking a session.

The successful pattern is narrow. One screen, the squad as a list, a colour per athlete, a single sentence of reason, and a recommendation phrased in training terms rather than physiological ones: full session, modified with no maximal sprints, or gym only. It arrives on a phone before the staff meeting rather than waiting behind a login. The head of performance can override any flag with a reason, and the override is recorded, because the override is often the most valuable data in the system.

What a custom build does specifically: shape the interface around the club's actual morning, which no vendor can do because every club's morning differs. It also handles the confidentiality boundary properly, which is the part clubs get wrong. Medical detail is special category personal data under UK and EU data protection law, and the coach does not need the diagnosis. The coach needs availability status. The doctor needs everything. A custom permission model makes that separation real at the field level, rather than relying on staff discipline about which screen they open in front of whom.

Problem 4: athletes move, and the record has to follow them

An academy player trains with the first team on Thursday, plays for the under 21s on Saturday, and gets called into a national team camp for ten days where a completely different staff loads him with no visibility to you. A senior player goes on loan and comes back in six months with a data gap. A trialist arrives for two weeks. A player transfers in and you inherit nothing but a medical summary.

Squad-scoped platforms handle the simple case, one team with a stable roster, and become awkward the moment an athlete belongs to two programmes at once. Yet dual programme athletes are exactly the ones at highest risk, because their total load is the sum of two plans neither of which sees the other.

What a custom build does: make the athlete the primary object and the team a relationship with dates, not a container. Load aggregates across every programme the athlete belongs to, so an academy player's Thursday first team session and Saturday age group match are one number. Camp periods are marked as external with whatever load estimate you can obtain, and clearly flagged as estimated rather than measured, because a system that silently treats absent data as zero load will tell you an athlete is fresh when he is not. Recruitment gets the same benefit: a target's available history imports into the same model, so you can look at a signing through your own lens rather than the seller's.

What this costs and how long it takes

Digital Heroes has delivered more than 2,000 projects, and for performance departments the shape is this. A first release covering ingestion from your existing hardware, athlete identity and session context, your load model with individual baselines, and a morning readiness board on mobile runs $60,000 to $140,000 over 10 to 16 weeks. A full platform adding medical and rehabilitation workflow with proper permission separation, gym prescription and compliance, squad and periodisation planning, multi-team pathways, and recruitment integration runs $150,000 to $400,000 phased across 6 to 12 months.

What pushes the number up in this category: the number of hardware vendors, since each ingestion is its own work and some deliver files rather than APIs. Live in-session data if you want the sideline tablet showing load during training rather than after it, which is a different engineering problem. Medical module scope, because rehabilitation pathways and return to play protocols are detailed and clinically sensitive. Video synchronisation, if you want to jump from a load spike to the clip. And the club-specific one: how much of your model exists only as one sport scientist's spreadsheet formulas. Extracting that is discovery time, and it is worth every hour because it is the first time the club has ever written its methodology down.

What holds it down: start with one squad, the two data sources that already drive decisions, and the morning board. Do not start with the medical module, however loudly it is requested.

Build versus buy, and when buying is the right call

Buy if you are a single senior squad with one GPS supplier, a performance staff of two or three, and no academy pathway to integrate. Smartabase and Kitman Labs are competent, they will be running next week rather than in four months, and a custom build would consume attention you do not have. Teamworks is a reasonable answer if your actual problem is operational coordination across staff rather than analysis depth. If the product fits your methodology, use it.

Build when two or more of these are true. Your analysis model is genuinely your own and your staff argue with vendor defaults rather than accepting them. You run three or more data sources and someone reconciles them weekly by hand. You have an academy or multiple teams and athletes move between them. You have changed hardware suppliers once and lost history, or you are about to. Or your entire methodology sits in a spreadsheet maintained by one person whose contract ends in June.

Our position is that the last one is the real trigger and clubs consistently underrate it. Hardware you can replace in a summer. A methodology that walks out of the building takes three seasons to rebuild, and the injuries in the meantime are real.

How to choose a developer for athlete management software

Ask them to model the domain in front of you. A team that has done this will draw athlete, team membership with date ranges, session with planned and actual context, measurement from a source, and a derived metric with a version. A team that draws players and workouts has built a consumer fitness app, and the difference will show the first time a loan player arrives mid-season.

Ask directly how they will separate medical data from performance data at the permission level, and how they treat special category data under data protection law. If the answer is user roles and nothing more, keep looking. This is the one area where a mistake becomes a legal problem rather than an inconvenience.

Ask which sports hardware they have actually integrated and what the export or API looked like. There is a large difference between a documented API and a nightly file drop with inconsistent columns, and the second one is more common than vendors admit.

Ask who owns the code, the raw data store, and the derived model, and get it written down before kickoff. The raw store matters more here than in most categories, because it is what makes your next supplier change a decision rather than a loss. At Digital Heroes the client owns all of it from the first commit.