I thought I had this figured out in 2023. I built a Node.js script that pulled data from the Google Fitness API to calculate my TDEE, derived the calorie costs for building muscle and fat from an actual nutrition textbook, committed the constants to code, and considered the problem solved. Past me closed the laptop very satisfied with himself.

Then Google Fit started getting deprecated, I lost the foundation that script was built on, and I ended up building Musclog - my own open-source fitness tracker. One of the features I wanted was weight projections: tell the app your goal and how many calories you’re eating, and it tells you how long it’ll take to get there.

So I plugged in the same logic from 2023. And the projections were consistently, confidently wrong.

If you’ve ever looked up how to lose or gain weight, you’ve probably heard the golden rule: 7700 calories equals one kilogram of fat (or roughly 3500 kcal per pound, if you’re used to the American version). This equivalence traces back to a 1958 paper by Max Wishnofsky in the American Journal of Clinical Nutrition - “Caloric equivalents of gained or lost weight” - and it’s been copy-pasted into every diet app and fitness calculator ever since. I’d been using it too. Turns out that’s the problem.

I went down a massive rabbit hole of human physiology research and thermodynamics to figure out how to accurately model weight projections in Musclog. Here’s what I learned, and what I built the second time around that actually worked.

When math isn’t mathing

To be upfront about what’s new here vs. what I already covered in 2023: the base constants - the calorie costs for building muscle and fat - are the same. What’s completely new is the P-ratio model that accounts for training experience, the Hall-Forbes weight loss equations, and the Lambert W function for calculating lean-to-fat loss ratios during a cut. Also, this time I actually traced the numbers back to the original papers instead of just asking ChatGPT - I mean, the Deep Research mode from Gemini got me to these papers, but I still had to trace the numbers back to the original sources.

I’ve been obsessively tracking my food and body composition for a few years now. I weigh my food. I track my macros. I log every workout. I am that guy, which at this point I’ve fully accepted.

So when Musclog started generating weight projections, I trusted the data. And the data told me that after two months of a modest caloric surplus and consistent training, I should have gained about 2.5 kg.

I had gained 1.1 kg (and yes, mostly fat, it is what it is).

At first I thought I was miscounting calories. Then I thought maybe I have wrongly calculated my TDEE (which is probably also true). But the numbers kept being off in the same direction, consistently, across multiple months. Something wasn’t right with the model itself.

So I started digging. And what I found was that the 7700 kcal/kg rule - the one used by basically every calorie calculator on the internet - makes one massive physiological mistake that I had never thought to question.

The difference between storing and building

The classic 7700 kcal/kg rule conflates the energy contained within a tissue with the energy required to construct that tissue. These are not the same thing.

When you look at the thermodynamic models for human tissue synthesis, things get interesting:

Adipose Tissue (Fat)

• Fat is about 86% lipid, 5% water, and a bit of protein.
• Energy stored inside 1 kg of fat: ~7730 kcal
• Energy cost to build 1 kg of fat: ~8840 kcal
• Efficiency: ~87%. The human body is depressingly efficient at storing excess energy as fat.

Skeletal Muscle

• Muscle is mostly water (~70%), about 24% protein, and some trace lipids.
• Energy stored inside 1 kg of muscle: ~1250 kcal (water has zero calories).
• Energy cost to build 1 kg of muscle: ~3900 kcal.
• Efficiency: ~32%. Muscle hypertrophy is an expensive, inefficient process - your body is constantly breaking down and rebuilding peptide bonds just to make you slightly less weak.

If you use the standard 7700 kcal/kg rule for a lean bulk, your app will vastly overestimate how much weight the user will gain, because building muscle consumes a huge chunk of energy in the construction process itself - energy that never ends up stored in the tissue.

This is why my projections were so far off. Musclog was assuming all weight gain was basically fat storage. In reality, a good chunk of my surplus was being burned as the metabolic cost of building muscle. The calories didn’t disappear - they were spent constructing new tissue, not filling it.

Down the rabbit hole

Once I understood the distinction between stored energy and construction cost, I had a new problem: where do I get the actual numbers?

I started with ChatGPT (obviously) - which, in my defense, is also exactly how I sourced these numbers in 2023, except that time I pasted the ChatGPT conversation directly into the blog post and considered it a citation. This time, I wanted something I could actually trace back to a real source. So I ended up on Google Books (thanks gemini) reading parts of the The Nutritionist: Food, Nutrition, and Optimal Health by Robert Wildman at 11pm on a Tuesday, which is not something I had planned for my week. I found the exact tissue composition breakdowns I needed there. For the synthesis efficiency percentages - 23% for protein, ~93% for lipids (and here is when the keto gang starts to get angry) - I traced those back to the thermodynamic analyses by J.P. Flatt, specifically his 1978 chapter “The biochemistry of energy expenditure,” which several of the more rigorous calorie modeling papers cite as a foundational source. And from all of that, I could finally do the math myself.

Here’s how the calculations actually work:

For muscle, 1 kg contains 200g of protein and 50g of lipids. Protein synthesis runs at about 23% efficiency - meaning it takes ~17 kcal to incorporate 1g of protein into tissue (4 kcal stored, 13 kcal burned in the process). Lipid synthesis runs at ~93% efficiency, so about 10 kcal per gram.

• Protein: 200 x 17 = 3400 kcal
• Fat: 50 x 10 = 500 kcal
• Total to build 1 kg of muscle: 3900 kcal

For body fat, 1 kg contains 850g of lipids and 20g of protein:

• Lipids: 850 x 10 = 8500 kcal
• Protein: 20 x 17 = 340 kcal
• Total to build 1 kg of fat: 8840 kcal

And there are the constants that ended up in my code. I also cross-referenced these against the data from my earlier TDEE tracking work to sanity-check the model against real numbers from my own body, which helped a lot.

Translating thermodynamics into code

To make Musclog accurate, I had to ditch the static math and build a dynamic model. First, I set up the energetic constants:

// Established thermodynamic model for human adipose tissue & skeletal muscle
const CALORIES_STORED_KG_FAT = 7730;
const CALORIES_BUILD_KG_FAT = 8840;

const CALORIES_STORED_KG_MUSCLE = 1250;
const CALORIES_BUILD_KG_MUSCLE = 3900;

But knowing the constants isn’t enough - we also need to know whether the user is primarily gaining fat or muscle. This is where the P-ratio comes in, and honestly the P-ratio was the thing that surprised me most in this whole research process. The concept was formalized by Gilbert Forbes in his 1987 book Human Body Composition and has since been studied extensively in the context of caloric surplus and deficit interventions. I’d been assuming my bulk was roughly 50/50 fat-to-muscle (which is the generic intermediate estimate), but the actual split is heavily influenced by training experience in ways I hadn’t accounted for.

A beginner - someone in their first year of lifting - can gain muscle dramatically faster relative to fat. Newbie gains are real, and they’re physiologically distinct from what happens to an intermediate or advanced lifter in a surplus. An advanced lifter in a bulk will end up storing proportionally more fat because the rate-limiting factor for muscle synthesis is already close to their genetic ceiling. Fun times.

I wrote a helper to determine this split based on the user’s self-reported experience level:

export function getGainFatFraction(liftingExperience?: LiftingExperience): number {
    switch (liftingExperience) {
        case 'beginner':
            return 0.4; // ~60% lean gain
        case 'advanced':
            return 0.6; // ~40% lean gain
        case 'intermediate':
        default:
            return 0.5; // 50/50
    }
}

Now, instead of blindly dividing a caloric surplus by 7700, Musclog calculates the effective caloric cost of gaining a kilogram of mixed body weight based on the user’s experience level:

export function getEffectiveKcalPerKgGain(liftingExperience?: LiftingExperience): number {
    const fatFraction = getGainFatFraction(liftingExperience);
    return fatFraction * CALORIES_BUILD_KG_FAT + (1 - fatFraction) * CALORIES_BUILD_KG_MUSCLE;
}

For a beginner: (0.4 * 8840) + (0.6 * 3900) = 5,876 kcal per kg. That is a massive difference from the generic 7700 kcal rule, and it’s exactly the kind of gap that explains why my projections were so consistently wrong.

The Goals Management screen in Musclog - this is where the projection engine actually runs. The calorie targets and weight goals you set here feed directly into the model described in this post.

The math of losing weight (the Hall-Forbes model)

Weight loss requires a completely different approach, and this is where things got genuinely complicated.

When you’re in a caloric deficit, you’re liberating stored energy rather than constructing new tissue - so the stored energy density is what matters now, not the construction cost. The problem is that you’re not losing pure fat. You lose a mix of fat and lean mass, and the ratio of that mix shifts depending on how lean you already are. The leaner you are, the more lean mass you’ll lose relative to fat in a deficit. This is a well-documented phenomenon and it has real implications for how you should calculate weight loss projections.

To model this accurately, I implemented the energy density equations from Kevin Hall’s 2008 paper “What is the required energy deficit per unit weight loss?” (published in the International Journal of Obesity) and the Forbes curve from the book mentioned above. And to calculate the lean-to-fat loss ratio dynamically based on current body fat percentage, I had to implement the Principal branch of the Lambert W function in TypeScript to solve the underlying differential equations - a technique described in Hall’s follow-up 2010 paper “Predicting metabolic adaptation, body weight, and body fat changes in humans” in the American Journal of Physiology:

function lambertW(z: number): number {
    if (z < -1 / Math.E) return NaN;
    if (z === 0) return 0;
    let w = z < 1 ? z : Math.log(z);
    for (let i = 0; i < 30; i++) {
        const ew = Math.exp(w);
        const f = w * ew - z;
        if (Math.abs(f) < 1e-10) return w;
        const fp = ew * (w + 1);
        w = w - f / fp;
    }
    return w;
}

I want to be upfront that I did not sit down and derive this from scratch - I worked from the Hall (2008) paper and adapted the implementation for TypeScript. But I did validate it against real data from my own cutting phases (courtesy of the tracking infrastructure I built back in 2023), and the model holds up well in practice.

Using this, Musclog dynamically calculates exactly how many calories are in a kilogram of weight lost for a specific user, based on their current body fat percentage. If a user doesn’t know their body fat, the app safely falls back to the classic ~7700 kcal/kg rule as a baseline - because some approximation beats no approximation.

This still isn’t perfect

I want to be honest about the limits here. These are population-level estimates. Individual variation in muscle protein synthesis efficiency, hormonal environment, training stimulus, sleep quality, and genetics means that no static model will perfectly predict what happens to any specific person’s body.

The P-ratio values I’m using (0.4 / 0.5 / 0.6) are reasonable averages from the literature, not individually calibrated numbers. In a future version, I’d love to calculate a user’s personal P-ratio from their historical data - Musclog already has everything it needs for that, it’s just not implemented yet.

But “more accurate than 7700 kcal/kg for everything” is a meaningful improvement over the status quo, and the projections have been noticeably better since I shipped this.

Conclusion

Building side projects is fun because you start off thinking “I’ll just make a simple calculator,” and a week later you’re reading 1970s physiology papers and implementing Lambert W functions in TypeScript at midnight. Classic.

By treating weight gain as an expensive construction project and weight loss as dynamic energy liberation, the projections in Musclog are vastly more accurate than the standard BMR+500 calculators floating around the web. And they actually matched my real-world data once I got it right, which is the most satisfying outcome in any side project.

This whole line of work started with the Google Fitness API TDEE script I wrote in 2023 - if you haven’t read that one and you’re into this kind of obsessive fitness tracking, it’s worth a look.

If you want to poke around the code, Musclog is fully open-source on GitHub. And if you actually want to use it, you can download it on Google Play. Drop a comment if you want to geek out over the math.

See you in the next one!