Why I built it
I have coached swimmers in Singapore, in mainland France and now in Guadeloupe. Like every coach I know, I ended up with the same pile: a file for the sessions, a spreadsheet for volume, intensity and training parameters, one for attendance, another one for the times, a federation website for the results, and my own head for everything that connected them.
What bothered me was the number of files every season, having to rebuild them from scratch each new season, the communication about training with the swimmers and the parents, and the handling and storage of everything I knew about a swimmer, his races and his training.
The Swimming Hub is my attempt at that problem: uniting everything in the same tool. From the simple attendance of swimmers, to the session, to the details of every length swum by the swimmer. The Swimming Hub is being built to be a complete tool for coaches and swimmers.
It is now a working platform in public beta, used to plan seasons, write sessions, track attendance and follow swimmers.
This page is about one part I find particularly interesting: the engine underneath, and the choices I had to make to build it.
What it actually does
The engine only reads one kind of material: times — race times, split times, relay times, and a few training tests. From that it works through five steps, and each one can be read on the Hub at four levels of difficulty (for teenagers, high-school students, field coaches and college coaches).
- It collects. Official results are pulled from the federation across a whole career, not just recent seasons. A coach can also enter times by hand.
- It situates a level. Every performance is compared against a reference built from ranking data, which turns a time into an index and places the swimmer on a thirteen-rung scale.
- It reads a profile. Two axes: sprint against distance, and one stroke against another. The engine refuses to label a swimmer typed on a single distance — you need around 3 to 5 performances to have the beginning of a profile.
- It produces training paces. This is the actual output. Physiological anchors — an aerobic reference, a critical speed, a threshold — are read from what the swimmer has demonstrated, and the training paces follow from them.
- It decides what the past is still worth. A ten-year-old time is not a current time. Nothing is ever deleted, but performances that no longer describe the swimmer stop feeding the calculations, and the reason is written next to them.
The full explanation lives on the Hub itself: how the engine works, in four reading depths from “I just want the idea” to the complete technical version with its bibliography, and the reference and the performance index on their own page.
Why these references, and not others
I wanted anchors that are measurable in a pool, by a coach, with a stopwatch, because that is what every coach can actually access.
So every anchor in the engine had to satisfy three conditions: it had to be published, it had to be obtainable from times alone, and the protocol had to be something a coach can actually run on a Tuesday evening.
- Critical speed is anchored on the 200/400 pair, following Dekerle and colleagues (2002), with the reliability of the repeated version checked against Scott, Burden & Dekerle (2024).
- The threshold is read from a 30-minute test, which Deminice and colleagues (2007) place at the same velocity as the 3.5 mmol threshold.
- The 12 × 25 test is convenient but it reads critical speed too fast. Mitchell and colleagues (2018) measured the bias and published the conversion, so the conversion is what the program applies rather than the raw result.
- Comparing one stroke to another — so that a 200 breaststroke and a 200 freestyle become comparable — rests on energy cost measured below the anaerobic threshold (Gonjo et al., 2018) and on the per-stroke energy cost equations of di Prampero et al. (2008), themselves built on Capelli et al. (1998).
- Reading a race from its splits follows the review by Gonjo & Olstad (2021), which is the reason the program treats the first 15 m as a mostly underwater phase rather than as swimming.
There are 52 references behind the engine. Each one is published with its DOI or PMID, marked as a primary study or a review, and — this is the part I insisted on — followed by one line saying what exactly it supports in the program. A reference that cannot be tied to a specific behaviour of the software does not belong in the bibliography.
How every number is labelled
The rule I set for myself early on: no number is published without saying where it comes from. Seven labels, applied to every figure in the technical documentation.
- Established — published in the literature, checked against the original text.
- Calculated — obtained by applying a published equation; the calculation can be redone by hand.
- Measured — computed on our own data, with the sample size written next to it.
- Derived — a combination of established values through a written, repeatable rule. Published nowhere as such.
- Directional — an assumed order of magnitude, bounded by the literature. Not a measurement, and it says so.
- Decision — a project choice, with its reason. Neither a measurement nor a source: a position held.
- Convention — a guardrail or a common-sense floor, with no physiological claim.
The reason this matters is transparency. A coach who disagrees with an output needs to know whether he is arguing with a published study, with my arithmetic, or with a choice I made. Those are three different arguments, and only the last one is negotiable.
It is very important to me that the process stays public, open to criticism and completely transparent. It lets anyone examine and judge my work knowing exactly how it was built. I worked alone on this project, so I can have biases or have made mistakes — and if I have, they need to be easy to see, so that they can be pointed out and corrected.
Where this sits in the rest of my work
This project did not start as a direct link to the rest of my work. It started as a tool for me to follow my swimmers’ training and share it with them. And during that process a simple question came up: “when I ask a swimmer to hold a pace over a distance, how do I decide what that pace should be for his level?” To answer it I had to build the swimmer profile — hence the engine. In doing so I organised my knowledge alongside the authors who work on the science of training — which is the same question I had been circling in my work on transferring swimming knowledge to freediving, and which I had left open there since 2019.
With The Swimming Hub I use a swimmer’s times to describe the engine inside him, in order to determine a physiological profile that helps him improve.
That does not mean swimming physiology equals freediving physiology. The interesting question is narrower and harder: which components developed and measured in swimming are relevant to a freediver, which transfer partially, and where does the transfer stop being valid. That is the thread I am picking up next.
Practical notes
The Hub is in French. I built it first for the coaches and the club I work with. An English version will come once the engine and its documentation are stable, and I intend to treat that as an international release. The Hub currently synchronises with the French Swimming Federation; in the future I hope to be able to synchronise with any swimming federation that publishes its competition results online.
It is free while in public beta, and it is the work of one person. If you are a coach and you try it, disagreement is useful to me — particularly disagreement with the paces it produces.
→ The Swimming Hub
→ How the engine works (French, four reading depths)
→ About the project
→ More about my background