I'm training for a charity ride up Mont Ventoux this summer. I kept hitting the wall on long training rides despite knowing the theory, such as Jeukendrup's work on carbohydrate oxidation rates, dual-source fueling, and the rest of it. The problem wasn't knowledge. It was that I'd forget to eat when I was suffering.
FlöFuel is an iPhone + Apple Watch app. You enter the products you're carrying (specific gels, drink mix, salt tablets), and it calculates a fueling schedule based on ride duration and intensity. The watch taps your wrist when it's time to act.
Product-aware scheduling. Most apps say "consume 30g carbohydrate." This one knows your specific products, such as that your Maurten 160 has 40g carbs, that your SaltStick caps are 215mg sodium, and tells you "take a gel now" or "take a salt tab."
Open-ended rides. If you don't know how long you'll be out, it shows rates and coverage instead of totals: "1 gel every 25 min, your supply covers about 3 hours."
Temperature-adjusted targets. Pulls ambient temperature and adjusts hydration and sodium upward in heat.
Carbohydrate targets from the literature. 40–90g/h scaled to intensity, with a GI absorption cap. Not bodyweight-based.
Implementation. The allocation problem (distributing intake across multiple products with coupled carb, sodium, and hydration constraints) is a variant of the bounded knapsack problem. The core services are formally specified in Z and the key safety properties have Lean 4 proofs. Probably overkill, but I wanted to be confident the algorithm was correct before trusting it mid-ride on a mountain.
No account, no backend, no tracking. Everything stays on device.
Happy to discuss the algorithm or the WatchConnectivity implementation, which turned out to be the hardest part.
kikibobo69•1h ago
FlöFuel is an iPhone + Apple Watch app. You enter the products you're carrying (specific gels, drink mix, salt tablets), and it calculates a fueling schedule based on ride duration and intensity. The watch taps your wrist when it's time to act.
Product-aware scheduling. Most apps say "consume 30g carbohydrate." This one knows your specific products, such as that your Maurten 160 has 40g carbs, that your SaltStick caps are 215mg sodium, and tells you "take a gel now" or "take a salt tab."
Open-ended rides. If you don't know how long you'll be out, it shows rates and coverage instead of totals: "1 gel every 25 min, your supply covers about 3 hours."
Temperature-adjusted targets. Pulls ambient temperature and adjusts hydration and sodium upward in heat.
Carbohydrate targets from the literature. 40–90g/h scaled to intensity, with a GI absorption cap. Not bodyweight-based.
Implementation. The allocation problem (distributing intake across multiple products with coupled carb, sodium, and hydration constraints) is a variant of the bounded knapsack problem. The core services are formally specified in Z and the key safety properties have Lean 4 proofs. Probably overkill, but I wanted to be confident the algorithm was correct before trusting it mid-ride on a mountain.
No account, no backend, no tracking. Everything stays on device.
Happy to discuss the algorithm or the WatchConnectivity implementation, which turned out to be the hardest part.