I'm building my own AI trainer. One user: me

I've been building a health app for a while now and this is the first time writing about it. The name is Life Controller, for now anyway, I'm open to changing it. React Native, SQLite, Claude API. One user: me, at least for now.

Why I'm building an AI trainer for myself

The why is pretty personal. I've been living between Vietnam and Portugal for the last two or three years, and that makes keeping a diet surprisingly hard. The food cultures are completely different, and in Vietnam I often genuinely don't know what I should be eating, or what's even in half the things I eat. On top of that I keep forgetting to eat between meals. Lunch happens, work absorbs me, and the next thing I register is a headache at 5pm. What I want is a personal trainer and a nutritionist in one place. Something that knows my plan and my context and nudges me before the gap becomes a problem.

The other half is training data. My Mi Band doesn't register swimming that well, and honestly not training either. So the idea is to take what the band does capture and combine it with the actual exercises I log and their caloric cost, and end up with one app that controls my health and my training. Hence the name.

There are less noble reasons too. Every fitness app out there is freemium and does whatever it wants with my data. I want to learn React Native. And I want to use AI to connect all of it. I'm just a builder, I guess.

How the planning hierarchy works

The structure is a hierarchy. A monthly theme at the top, AI-suggested, I confirm it. That breaks into a weekly goal, which breaks into daily soft targets, and then real-time adaptation on top, so bad sleep last night changes today's plan. Everything is soft. Weight is a monthly goal, not a weekly pass or fail, because weekly weight is mostly noise. And deviations are treated as signals, not failures. If I swap swimming for running every single time it's scheduled, the app should figure out I prefer running and stop scheduling swims.

The feature I underestimated is a freeform weekly note. Every Sunday I write a few sentences, things like traveling Wednesday, knee feels off, want more volume, and the AI plans around it. I originally treated it as a nice-to-have. Turns out it's the most important planning input in the whole app. A text box plus a model that can read beats any structured form I could have designed.

Designing for exactly one user

Being the only user changes a lot of decisions. No accounts, no cloud sync, everything offline in SQLite on the device. No social features. Distribution is TestFlight to my own phone. The main navigation is a long-press on the Today tab that fans out Today, Week, Month. Terrible discoverability for a real product. Completely fine when the only user is the person who designed the gesture.

The privacy trade I haven't resolved

The part I'm still hovering over is privacy. This thing knows my meals, my sleep, my weight, my blood work, what pills I take. The data itself stays on my device, but the coaching runs through an AI API, so context does leave the phone for every request. For my own use I've made peace with that trade, though I keep wondering if running an open source model myself would be the better answer. Not for now.

Which connects to the other open question: whether this ever goes public. I might. I genuinely don't know how or when, but the how is what I keep turning over. Straight subscription, or freemium with the AI coaching as the paid layer. The per-request AI cost means a free tier isn't free for me, so the model matters more than it would for a normal app. For now it's just for me.

The AI layer: model routing and prompt caching

On the engineering side, the part I find most interesting is the AI layer. Not every log deserves the same intelligence, so requests route across three model tiers. Quick logs like water go to Haiku, fast and cheap. Meal photos, workout coaching and the morning plan go to Sonnet because they need vision and actual reasoning. The Sunday synthesis and blood work correlation go to Opus, since that's genuine multi-source analysis. A water log on a frontier model would be burning money for nothing.

The bigger cost lever is prompt caching. Every request carries the same big context block: profile and goals, the weekly note, the last seven days of summarized logs, detected patterns, latest blood work. With caching, the repeated content gets about a 90% discount. The thing that makes it clean is that memory writes only happen at fixed checkpoints, evening review, Sunday synthesis, month-end. Context only changes at known moments, so there's no cache invalidation logic at all. Rebuild at each checkpoint plus once at 6am. Boring and predictable, which is the point.

The Mi Band problem

The hard problem waiting for me is the Mi Band itself. It's already paired to the official app, which complicates direct BLE access. Options were extracting the auth token from the official app, which needs root or ADB gymnastics, or re-authenticating with the community protocol. Going with the community route. Gadgetbridge already solved the auth flow, I just need to implement it on react-native-ble-plx. That's also what forces me off Expo Go and into a development build, so I'm staying in Expo Go until that milestone.

One thing I deliberately shelved: a parent-child agent setup where a coordinator delegates to specialist agents for sleep, nutrition and training. Designed it, got excited, then admitted the current single-call architecture with model routing handles everything the app actually does today.

Where it stands

Current state: the prototypes are basically ready. All done with Claude Design, and the amount of tokens spent was insane ahah. Now we go to the engineering part. I think I'll have this ready by the end of next month.