# One month building my AI trainer. It tells me things now > A month ago the prototypes were done and the engineering was still ahead of me. Then reality showed up. The Mi Band reverse-engineering plan I abandoned, the weekly note that learned to edit my plan, and the week the app finally started telling me why yesterday went the way it did. Author: Miguel Félix (Miguel Félix Moreira, Frontend Engineer at AnubisNetworks) — https://www.miguelfelix.dev/#miguel Published: 2026-07-17 Reading time: 5 min read Canonical URL: https://www.miguelfelix.dev/writing/one-month-building-my-ai-trainer-it-tells-me-things-now --- I haven't posted in a while. Life got in the way, which is the most boring reason to give but also the true one. Here's some of the life. I got back to Portugal three weeks ago. One of the first things I sorted out once I was settled was a pool, and the one near me is 25 meters instead of the 50 I'd gotten used to. I assumed that would feel like a downgrade. It doesn't. Something about the shorter length, the more frequent turns, the rhythm of it, and I've gone from barely scraping 600m in the old 50m pool to swimming 1.3km and having to climb out only because we get one hour per session and the clock runs out on me. I didn't get fitter in three weeks. The environment changed and my body just responded to it. Hold onto that, because it turned out to be the whole point of the other thing I've been building. ## A month in: what the app does now The other thing is the app. Last time I wrote about it, it was mostly an idea and a pile of prototypes, the why worked out and the engineering still sitting in front of me. A month later the repo exists, it lives on my phone, and it logs what I eat, how I sleep, whether I skipped leg day, and as of this week it tells me why yesterday went the way it did. That last part is the one I was building toward the entire time, and it took a month of unglamorous work to earn the right to it. ## The bet: logging is easy, understanding is hard The bet at the start was simple. Logging isn't the hard part. Understanding is. Every fitness app I've used is good at capture and bad at synthesis. You type in your water, your meals, your workouts, and it hands you back the same numbers you just entered, plotted a little differently. That's a mirror. I didn't want a mirror. I wanted something that could look at three weeks of my data and tell me something I hadn't already noticed, the way the pool told me something about my swimming that I never would have worked out from staring at my old times. ## Foundation first, on purpose So the first few days were boring on purpose. A SQLite schema, a navigation shell, a design system nobody will ever compliment me on. Foundation. The kind of work that doesn't feel like progress until a week later, when it's the reason everything after it moves faster. ## From a form into a coach Then it stopped being a form and started being a coach. The freeform weekly note, the feature I said last time I'd underestimated, is still the one that matters most, and it grew a second half this month. It used to be something the AI just read. Now the coach can propose changes to the plan and actually apply them, so "traveling Wednesday, knee feels off" doesn't only get acknowledged, it gets acted on and I approve it. That was the whole point of soft, adaptive planning, and it took a month to close the loop from the model reading my context to the model editing the plan. The "deviations are signals, not failures" idea got real teeth too: deload weeks kick in before I've ground myself down instead of after, and an injury log swaps out push exercises on its own instead of making me explain my shoulder to a form every time. Nobody warns you that most of the work in an "AI feature" isn't the model call. It's the plumbing around it. It's knowing when the plan should defer to reality instead of scolding you for missing it. ## The Mi Band reverse-engineering plan I abandoned The Mi Band did not go the way I planned, and that's the part I most want to write down. Last post I was confident about the community-protocol route: Gadgetbridge's auth flow on top of react-native-ble-plx, direct control of the band, own the device end to end. I built toward exactly that. A whole Mi Band management screen, twelve sections, alarm CRUD, the works, like I was going to run that thing myself. Then reality showed up. Half those sections just don't work against Xiaomi's encrypted protobuf protocol without a fight I didn't actually want to have, so I commented them out. Not fixed, not deferred. Commented out, which is its own kind of admission. What I do instead is almost embarrassingly simpler. Mi Fitness stays installed and signed in, it feeds Health Connect on Android and HealthKit on iOS, and my app just reads from there. BLE only runs during onboarding now, to detect the band and confirm it's paired, and that's it. I spent real energy planning a reverse-engineering project and the actual answer was to let the official app do its job and read the OS health store like everyone else. Mildly humbling, clearly better. Steps and workouts and metrics started flowing within a day of making that call, instead of the weeks of protocol debugging I'd talked myself into. The Expo Go plan didn't survive contact with day one either. I said I'd stay in Expo Go until BLE forced a dev build. The very first real commit was a bare project with ios/ and android/ committed from the start. Plans are cheap. ## Dogfooding as a merciless PM The dogfooding was brutal, in the good way. Being the only user means every bug report is me, mid-set or mid-meal, going "wait, that's wrong." Sessions double-logging themselves. Sleep debt charging me the full deficit on the nights the band didn't sync, instead of excusing the gap. A stale exercise swap sticking around after I'd already changed my mind. The gym log sheet cutting off text. Missed dinners not backfilling right. None of these show up in a code review. They show up because you're standing in a gym at 7am wondering why the app thinks last night went worse than it did. Using your own app every day is a merciless PM. It will not let you ship something that's almost right. ## Review Yesterday, and correlation detection And then, this week, the thing I actually wanted. "Review Yesterday" is an on-demand recap that runs a causal read on the day instead of replaying the numbers, an actual "here's probably why yesterday went like that." Next to it, correlation detection between water intake and how much I eat, and between meal timing and snacking later. That's the "if I keep swapping swimming for running, the app should notice I prefer running" instinct from the first post, finally running instead of just designed. The one that's dull to describe but answers the original problem: camera-first meal logging. Point the phone at the plate, add a line of context if I want, done. That's a direct reply to the thing that started all of this, standing in Vietnam not knowing what's in half of what I'm eating. Deterministic tagging underneath means the model isn't re-guessing the same meal category every time I log something similar. And the small things that only matter because I use this daily, like a plate calculator and a warm-up generator so I stop doing math between sets. ## Where it stands now Where it stands: still one user, still no accounts, no cloud sync, everything on-device. I still haven't resolved how I feel about the coaching context leaving the phone on every request. That hasn't gotten easier to think about, I've just kept using it anyway, which is its own kind of answer and not one I'm proud of. Whether this ever goes public is exactly as unresolved as it was last time I wrote about it. What's different is that the app tells me things now instead of just recording them. That was always the actual goal, and it took a month of infrastructure and one abandoned reverse-engineering plan to get there. Same as the pool, really. I just needed something paying closer attention than I was.