The athlete asked a simple question: am I getting better? My colleague, a trainer and physiotherapist who works almost exclusively with combat athletes, opened his laptop. He pulled up Trainerize. He exported a report. He opened another tab to compare it against last month. He opened another tab to compare it against the month before that. He wrote numbers down in a notebook because the platform would not let him see them side by side. Twenty minutes later, he had a partial answer. This is the part that bothered me. Not the work itself, but what the work was costing. Every hour he spent assembling data was an hour he was not spending coaching. Every athlete who got a slower answer was an athlete who got a less specific answer. The bottleneck was not his competence. The bottleneck was that the tools he had were never designed for the kind of longitudinal, exercise-specific insight he actually wanted to give. That is the problem CombatIQ exists to solve.
The constraint
I gave myself seven days. Not because seven days is some magic number. Because I needed a constraint that would force me to ship something instead of perfecting it in my head for three months. (I have a note on my phone called "things to build." It has too many entries. Some of them are years old.) This was my first real coding project. Not the first time I had written a line of code, but the first time I committed to building a thing that an actual person would actually use. The temptation to learn everything before building anything is real. Seven days made that temptation impossible.
Why I was the right person to build this
I have spent a lot of time inside combat sports. I have boxed. I have played hockey. I have coached. I have been the athlete asking the question my colleague was now trying to answer. I know what a good check-in feels like, and I know what a generic one feels like. I know the kinds of questions a fighter asks the week before a competition, and the kinds of questions they ask in the long, quiet middle of a training block when nothing seems to be moving. That context shaped every product decision. CombatIQ is not a generic athlete dashboard. It is a tool built around a specific user (a trainer working with combat athletes) doing a specific job (turning scattered data into an insight a fighter can act on inside the same conversation where they asked). My colleague brought the clinical and training expertise. I brought the athlete's perspective and the product instinct. The dashboard sits at that intersection.
The flow
I designed it around how he already worked, not around how a textbook said the workflow should look. The first step is the check-in. Athletes fill out a short form covering quality-of-life measurements: sleep, soreness, mood, weight, energy, anything that does not show up in a training log but absolutely shapes how they perform. This is the layer most performance tools either ignore or bolt on awkwardly. It is also the layer my colleague kept telling me was the most predictive signal he had, and the one he had no good way to track over time. The second step is the export. He runs his sessions through Trainerize, which is the source of truth for prescribed work, sets, reps, loads, and athlete-logged completion. He exports the report and uploads it to CombatIQ. The dashboard parses the file and stitches it together with the check-in data so everything finally lives in one place. The third step is the insight. This is where the twenty minutes get bought back. Instead of digging through tabs and notebooks, he pulls up a longitudinal view of any athlete, across any specific exercise, with any quality-of-life metric overlaid on top. From there he generates a report and delivers it inside the same conversation where the athlete asked the question. That was the whole point. Compress the twenty-minute scramble into a two-minute glance.
What I cut
A lot. I had ideas for AI-generated programming recommendations. I had ideas for a public-facing athlete view. I had ideas for biometric integrations, a mobile companion app, a coaching marketplace, a community layer. None of that shipped in week one. None of that needed to. The version that went live did one thing well: it took data my colleague was already collecting and turned it into a view he could actually use. That was the job. Everything else was someone else's product, or my product later, or no one's product at all. Hard to tell on day three. Easier to tell on day seven. The discipline of cutting was harder than the discipline of building. That was the surprise.
What I learned
The biggest unlock when you are building a tool for a specific user is sitting next to them while they do the thing the tool is supposed to fix. Half of what shipped in CombatIQ came from watching him work and asking, "what just slowed you down?" The other half came from being able to answer that question myself, because I had been on the other side of the table as the athlete waiting for the answer. Being a former athlete made me build differently. I knew, viscerally, what it feels like to be on the receiving end of a vague check-in. I made decisions to protect against that, even when no one was asking me to.
And shipping a thing in seven days teaches you more than thinking about it for seven months. (I am aware of how this sounds. It is also true.)
Where it is now
CombatIQ is in use with one trainer and a small roster of athletes. It is rough in places. The styling needs work. The upload flow has edge cases I am still cleaning up. There is no marketing site, no signup page, no roadmap on a Notion doc somewhere. But athletes are getting faster, more specific answers to the question that started this whole thing. And my colleague is spending his time coaching instead of compiling. That is what week one was supposed to do. The rest is just showing up.