FuelPilot started from a simple need: most nutrition tracking tools are either too generic, too fiddly (I always really struggled to log food on the well known apps), or too detached from the reality of training.
If you care about performance, “how much did I eat?” is only part of the picture. What also matters of course day to day is the relationship between food, training load, recovery, and the choices you make as a result of all these data points. I wanted something that would allow me see that clearly, without disappearing into endless manual admin.
So FuelPilot began as a practical personal project: a daily nutrition and training-fuelling app designed to support real decisions. The aim was not to build a bloated all-purpose platform. It was to create something reliable enough to trust and simple enough to use every day.
The core idea is straightforward. FuelPilot should make it quick to log food, pull in planned and completed training, calculate a clear daily target using a transparent method, and show useful weekly patterns rather than just a pile of disconnected numbers.
That has shaped the first version of the project. The current v1 focus is on a few things that matter most: reliable meal logging, a deterministic daily target engine, clear on-screen calculations, planned and actual training integration, short daily check-ins, and a weekly summary that is genuinely actionable.
Under the surface, a lot of the work so far has been about reliability rather than glamour. I’ve already put in atomic database writes, and a correction for Strava-derived calorie estimates when only watts-based fallback data is available.
The current phase is mostly hardening. I’m tightening input validation, preventing duplicate check-ins, fixing local date handling around day boundaries, adding explicit timeouts for external API calls, improving restart and backup behaviour, and making workout deletion more robust by moving away from index-based logic. In other words, this is the part where a personal prototype starts being turned into something stable enough for repeated real-world use.
Integration has also been a key part of the design. At the moment, FuelPilot uses my Strava for actual training load and TrainingPeaks calendar data for planned sessions. The logic is intentionally simple: completed workouts take priority, then planned workouts, then none. That gives a daily target based on the best available training signal, rather than trying to be clever in ways that make the system harder to trust.
Looking ahead, the immediate goal is a marketable beta: not feature-maximal, but dependable. The test is whether it can survive daily use without silent data loss, inconsistent calculations, duplicate workout problems, or enough friction to make logging feel like a chore. If it cannot do those basics well, there is no point pretending it is ready.
Beyond that, there are obvious next steps. I want better error isolation across dashboard widgets, clearer explanation labels in the UI, and eventually broader passive-activity context through Apple Health or Google Fit. There are also features I’ve deliberately kept out of scope for now, including native mobile apps, heavy social features, and AI-based photo calorie estimation. Those may come later, but only if the core system earns them.
At heart, FuelPilot is an attempt to build the kind of tool I would actually want to use: something practical, transparent, and good enough to support better day-level decisions about fuelling and training. That is still the standard I’m using as I build it.
I use the app several times a day to plan my meals. I log my food and check how that stacks up against my workout needs. The results are definitely suprising – I needed 4,000 calories today, for example – and haven’t quite hit the target – and I overate on fat. I’ve been using the app for a week or so now and I do think it’s helping me recover better, fuel better, eat more protein than I ever thought sensible. I’m pretty excited by it to be honest.
abstractlines 
Leave a comment