![\"Tela](\"../../uploads/blog/2026/03/screenshot-6.png\")
Achei que tinha resolvido isso em 2023. Criei um script em Node.js que puxava dados da Google Fitness API para calcular meu TDEE, derivei os custos calóricos para construir músculo e gordura a partir de um livro de nutrição de verdade, joguei as constantes no código e considerei o problema resolvido. O eu do passado fechou o laptop muito satisfeito consigo mesmo.
\nAí o Google Fit começou a ser descontinuado, perdi a base sobre a qual o script estava construído e acabei criando o Musclog - meu próprio app de fitness open-source. Uma das funcionalidades que eu queria eram projeções de peso: diga ao app seu objetivo e quantas calorias você está comendo, e ele te diz quanto tempo vai levar para chegar lá.
\nEntão pluguei a mesma lógica de 2023. E as projeções estavam consistentemente, confiantemente erradas.
\nSe você já pesquisou como perder ou ganhar peso, provavelmente já ouviu a regra de ouro: 7700 calorias equivalem a um quilograma de gordura (ou cerca de 3500 kcal por libra, se você usa o sistema americano). Essa equivalência remonta a um artigo de 1958 de Max Wishnofsky no American Journal of Clinical Nutrition - “Caloric equivalents of gained or lost weight” - e foi copiada e colada em todo app de dieta e calculadora de fitness desde então. Eu também estava usando. Acontece que esse é o problema.
\nFui fundo num buraco de pesquisa sobre fisiologia humana e termodinâmica para entender como modelar projeções de peso com precisão no Musclog. Aqui está o que aprendi, e o que construí da segunda vez que realmente funcionou.
\nPara ser transparente sobre o que é novo aqui versus o que eu já cobri em 2023: as constantes base - os custos calóricos para construir músculo e gordura - são as mesmas. O que é completamente novo é o modelo de P-ratio que leva em conta a experiência de treino, as equações de perda de peso de Hall-Forbes e a função Lambert W para calcular as proporções de perda de gordura versus massa magra durante um cutting. Além disso, dessa vez eu realmente rastreei os números de volta aos artigos originais em vez de só perguntar pro ChatGPT. (Eu perguntei pro ChatGPT em 2023. Publiquei a conversa como fonte. Eu sei.)
\nFaz alguns anos que acompanho minha alimentação e composição corporal de forma obsessiva. Peso minha comida. Registro meus macros. Anoto cada treino. Eu sou esse cara, o que a essa altura já aceitei completamente.
\nEntão quando o Musclog começou a gerar projeções de peso, confiei nos dados. E os dados me disseram que após dois meses de superávit calórico moderado e treino consistente, eu deveria ter ganhado cerca de 2,5 kg.
\nEu tinha ganhado 1,1 kg (e sim, principalmente gordura, é o que é).
\nA princípio pensei que estava errando na contagem de calorias. Depois achei que talvez tivesse calculado meu TDEE errado (o que provavelmente também é verdade). Mas os números continuavam errados na mesma direção, consistentemente, ao longo de vários meses. Algo estava errado no próprio modelo.
\nEntão comecei a investigar. E o que descobri foi que a regra das 7700 kcal/kg - usada por basicamente toda calculadora de calorias na internet - comete um erro fisiológico enorme que eu nunca havia questionado.
\nA regra clássica das 7700 kcal/kg confunde a energia contida em um tecido com a energia necessária para construí-lo. Essas duas coisas não são a mesma.
\nQuando você olha para os modelos termodinâmicos de síntese de tecido humano, as coisas ficam interessantes:
\nTecido Adiposo (Gordura)
\nMúsculo Esquelético
\nSe você usar a regra padrão de 7700 kcal/kg para um lean bulk, seu app vai superestimar muito o quanto o usuário vai ganhar, porque construir músculo consome uma boa parte da energia no próprio processo de construção - energia que nunca vai parar dentro do tecido.
\nÉ por isso que minhas projeções estavam tão erradas. O Musclog estava assumindo que todo ganho de peso era basicamente armazenamento de gordura. Na realidade, boa parte do meu superávit estava sendo queimada como custo metabólico da construção muscular. As calorias não desapareceram - foram gastas construindo tecido novo, não preenchendo-o.
\nUma vez que entendi a distinção entre energia armazenada e custo de construção, surgiu um novo problema: de onde tiro os números reais?
\nComecei pelo ChatGPT (obviamente) - que, em minha defesa, também foi exatamente como obtive esses números em 2023, só que naquela vez colei a conversa com o ChatGPT diretamente no post do blog e considerei isso uma citação. Dessa vez, eu queria algo que pudesse rastrear de verdade até uma fonte real. Então acabei no Google Books lendo partes de The Nutritionist: Food, Nutrition, and Optimal Health, do Robert Wildman, às 23h de uma terça-feira, o que definitivamente não estava nos meus planos para a semana. Encontrei lá os detalhamentos exatos de composição de tecidos que precisava. Para as porcentagens de eficiência de síntese - 23% para proteína, ~93% para lipídios (é aqui que a turma do keto começa a ficar com raiva) - rastreei esses números de volta às análises termodinâmicas de J.P. Flatt, especificamente seu capítulo de 1978 “The biochemistry of energy expenditure”, citado como fonte fundamental em vários dos artigos mais rigorosos sobre modelagem calórica. E com tudo isso, finalmente consegui fazer a matemática eu mesmo.
\nVeja como os cálculos funcionam na prática:
\nPara músculo, 1 kg contém 200g de proteína e 50g de lipídios. A síntese proteica roda com cerca de 23% de eficiência - ou seja, são necessários ~17 kcal para incorporar 1g de proteína ao tecido (4 kcal armazenadas, 13 kcal queimadas no processo). A síntese lipídica roda com ~93% de eficiência, então cerca de 10 kcal por grama.
\nPara gordura corporal, 1 kg contém 850g de lipídios e 20g de proteína:
\nE essas são as constantes que foram parar no meu código. Também cruzei esses dados com os meus dados do trabalho anterior de rastreamento de TDEE para validar o modelo contra números reais do meu próprio corpo, o que ajudou bastante.
\nPara deixar o Musclog preciso, tive que abandonar a matemática estática e construir um modelo dinâmico. Primeiro, defini as constantes energéticas:
\n// Established thermodynamic model for human adipose tissue & skeletal muscle\r\nconst CALORIES_STORED_KG_FAT = 7730;\r\nconst CALORIES_BUILD_KG_FAT = 8840;\r\n\r\nconst CALORIES_STORED_KG_MUSCLE = 1250;\r\nconst CALORIES_BUILD_KG_MUSCLE = 3900;Mas conhecer as constantes não é suficiente - também precisamos saber se o usuário está ganhando principalmente gordura ou músculo. É aqui que entra o P-ratio, e honestamente o P-ratio foi a coisa que mais me surpreendeu em todo esse processo de pesquisa. O conceito foi formalizado por Gilbert Forbes em seu livro de 1987 Human Body Composition e desde então foi extensivamente estudado no contexto de intervenções de superávit e déficit calórico. Eu estava assumindo que meu bulk era aproximadamente 50/50 gordura-músculo (que é a estimativa genérica para intermediários), mas a divisão real é fortemente influenciada pela experiência de treino de formas que eu não havia considerado.
\nUm iniciante - alguém no primeiro ano de musculação - pode ganhar músculo dramaticamente mais rápido em relação à gordura. Os ganhos de novato são reais e são fisiologicamente distintos do que acontece com um praticante intermediário ou avançado em superávit. Um levantador avançado em um bulk vai acabar armazenando proporcionalmente mais gordura porque o fator limitante para a síntese muscular já está próximo do seu teto genético. Que delícia.
\nEscrevi uma função auxiliar para determinar essa divisão com base no nível de experiência declarado pelo usuário:
\nexport function getGainFatFraction(liftingExperience?: LiftingExperience): number {\r\n switch (liftingExperience) {\r\n case 'beginner':\r\n return 0.4; // ~60% lean gain\r\n case 'advanced':\r\n return 0.6; // ~40% lean gain\r\n case 'intermediate':\r\n default:\r\n return 0.5; // 50/50\r\n }\r\n}Agora, em vez de dividir cegamente o superávit calórico por 7700, o Musclog calcula o custo calórico efetivo de ganhar um quilograma de peso corporal misto com base no nível de experiência do usuário:
\nexport function getEffectiveKcalPerKgGain(liftingExperience?: LiftingExperience): number {\r\n const fatFraction = getGainFatFraction(liftingExperience);\r\n return fatFraction * CALORIES_BUILD_KG_FAT + (1 - fatFraction) * CALORIES_BUILD_KG_MUSCLE;\r\n}Para um iniciante: (0.4 * 8840) + (0.6 * 3900) = 5.876 kcal por kg. Isso é uma diferença enorme em relação à regra genérica das 7700 kcal, e é exatamente esse tipo de lacuna que explica por que minhas projeções estavam tão consistentemente erradas.
A tela de Gerenciamento de Metas no Musclog - é aqui que o motor de projeção realmente roda. As metas calóricas e de peso que você define aqui alimentam diretamente o modelo descrito neste post.
\nA perda de peso exige uma abordagem completamente diferente, e é aqui que as coisas ficaram genuinamente complicadas.
\nQuando você está em déficit calórico, está liberando energia armazenada em vez de construir novo tecido - então o que importa agora é a densidade energética armazenada, não o custo de construção. O problema é que você não perde gordura pura. Você perde uma mistura de gordura e massa magra, e a proporção dessa mistura muda dependendo de quão magro você já está. Quanto mais magro você está, mais massa magra você perde em relação à gordura num déficit. Esse é um fenômeno bem documentado e tem implicações reais para como calcular projeções de perda de peso.
\nPara modelar isso com precisão, implementei as equações de densidade energética do artigo de 2008 de Kevin Hall “What is the required energy deficit per unit weight loss?” (publicado no International Journal of Obesity) e a curva de Forbes do livro mencionado acima. E para calcular a proporção de perda de gordura versus massa magra dinamicamente com base no percentual de gordura corporal atual, tive que implementar o ramo principal da função Lambert W em TypeScript para resolver as equações diferenciais subjacentes - uma técnica descrita no artigo de acompanhamento de Hall em 2010 “Predicting metabolic adaptation, body weight, and body fat changes in humans” no American Journal of Physiology:
\nfunction lambertW(z: number): number {\r\n if (z < -1 / Math.E) return NaN;\r\n if (z === 0) return 0;\r\n let w = z < 1 ? z : Math.log(z);\r\n for (let i = 0; i < 30; i++) {\r\n const ew = Math.exp(w);\r\n const f = w * ew - z;\r\n if (Math.abs(f) < 1e-10) return w;\r\n const fp = ew * (w + 1);\r\n w = w - f / fp;\r\n }\r\n return w;\r\n}Quero deixar claro que não derivei isso do zero - trabalhei a partir do artigo de Hall (2008) e adaptei a implementação para TypeScript. Mas validei contra dados reais das minhas próprias fases de cutting (graças à infraestrutura de rastreamento que criei em 2023), e o modelo se sustenta bem na prática.
\nCom isso, o Musclog calcula dinamicamente exatamente quantas calorias estão em um quilograma de peso perdido para um usuário específico, com base no seu percentual de gordura corporal atual. Se o usuário não souber seu percentual de gordura, o app volta com segurança para a regra clássica de ~7700 kcal/kg como base - porque alguma aproximação é melhor que nenhuma.
\nQuero ser honesto sobre as limitações aqui. Essas são estimativas em nível populacional. A variação individual na eficiência de síntese proteica muscular, ambiente hormonal, estímulo de treino, qualidade do sono e genética significa que nenhum modelo estático vai prever perfeitamente o que acontece com o corpo de uma pessoa específica.
\nOs valores de P-ratio que estou usando (0,4 / 0,5 / 0,6) são médias razoáveis da literatura, não números individualmente calibrados. Numa versão futura, adoraria calcular o P-ratio pessoal do usuário a partir dos seus dados históricos - o Musclog já tem tudo o que precisa para isso, só não está implementado ainda.
\nMas “mais preciso do que 7700 kcal/kg para tudo” é uma melhoria significativa em relação ao status quo, e as projeções ficaram visivelmente melhores desde que lancei isso.
\nConstruir side projects é divertido porque você começa pensando “vou fazer uma calculadora simples,” e uma semana depois está lendo artigos de fisiologia dos anos 70 e implementando funções Lambert W em TypeScript à meia-noite. Clássico.
\nTratando o ganho de peso como um projeto de construção caro e a perda de peso como liberação dinâmica de energia, as projeções no Musclog são muito mais precisas do que as calculadoras padrão de BMR+500 espalhadas pela web. E elas realmente bateram com meus dados do mundo real depois que acertei o modelo, o que é o resultado mais satisfatório em qualquer side project.
\nTodo esse trabalho começou com o script de TDEE com a Google Fitness API que escrevi em 2023 - se você não leu aquele e curte esse tipo de rastreamento obsessivo de fitness, vale a pena dar uma olhada.
\nSe quiser fuçar no código, o Musclog é totalmente open-source no GitHub. E se quiser usar o app de verdade, pode baixar no Google Play. Deixa um comentário se quiser conversar sobre a matemática.
\nAté a próxima!
","fields":{"postHashId":"Y29kaW5ndHJ1ZW51bGwyMDI2LTAyLTEyVDAwOjAwOjAwLjAwMFo=","slug":"/2026/2026-02-12-por-que-a-regra-das-7700-calorias-e-falha-e-como-eu-a-corrigi-no-meu-app.pt-br/","path":"/blog/coding/por-que-a-regra-das-7700-calorias-e-falha-e-como-eu-a-corrigi-no-meu-app/","locale":"pt-br"},"readingTime":{"minutes":12.01},"frontmatter":{"path":"por-que-a-regra-das-7700-calorias-e-falha-e-como-eu-a-corrigi-no-meu-app","allowComments":true,"title":"Por que a regra das 7700 calorias é falha (e como eu a corrigi no meu app)","date":"2026-02-12T00:00:00.000Z","categories":["coding"],"tags":["typescript","musclog","algorithms","fitness","nutrition","bodybuilding"],"hideExcerpt":false,"subtitle":"Spoiler: seu corpo não leu o manual"}},"categoryImage":{"childImageSharp":{"original":{"width":1920,"height":1080,"src":"/static/categories_coding-aa17d098a6a0d8e0a764a345865f5ffb.jpg"}}}},"pageContext":{"alternativeHtml":"![\"Ilustração](\"/static/9e01cdc27fc3fbd2671706b845005fe1/42a19/7700-calorie-illustration.png\" "\\"Ilustração")
\n \n Achei que tinha resolvido isso em 2023. Criei um script em Node.js que puxava dados da Google Fitness API para calcular meu TDEE, derivei os custos calóricos para construir músculo e gordura a partir de um livro de nutrição de verdade, joguei as constantes no código e considerei o problema resolvido. O eu do passado fechou o laptop muito satisfeito consigo mesmo.
\nAí o Google Fit começou a ser descontinuado, perdi a base sobre a qual o script estava construído e acabei criando o Musclog - meu próprio app de fitness open-source. Uma das funcionalidades que eu queria eram projeções de peso: diga ao app seu objetivo e quantas calorias você está comendo, e ele te diz quanto tempo vai levar para chegar lá.
\nEntão pluguei a mesma lógica de 2023. E as projeções estavam consistentemente, confiantemente erradas.
\nSe você já pesquisou como perder ou ganhar peso, provavelmente já ouviu a regra de ouro: 7700 calorias equivalem a um quilograma de gordura (ou cerca de 3500 kcal por libra, se você usa o sistema americano). Essa equivalência remonta a um artigo de 1958 de Max Wishnofsky no American Journal of Clinical Nutrition - “Caloric equivalents of gained or lost weight” - e foi copiada e colada em todo app de dieta e calculadora de fitness desde então. Eu também estava usando. Acontece que esse é o problema.
\nFui fundo num buraco de pesquisa sobre fisiologia humana e termodinâmica para entender como modelar projeções de peso com precisão no Musclog. Aqui está o que aprendi, e o que construí da segunda vez que realmente funcionou.
\nPara ser transparente sobre o que é novo aqui versus o que eu já cobri em 2023: as constantes base - os custos calóricos para construir músculo e gordura - são as mesmas. O que é completamente novo é o modelo de P-ratio que leva em conta a experiência de treino, as equações de perda de peso de Hall-Forbes e a função Lambert W para calcular as proporções de perda de gordura versus massa magra durante um cutting. Além disso, dessa vez eu realmente rastreei os números de volta aos artigos originais em vez de só perguntar pro ChatGPT. (Eu perguntei pro ChatGPT em 2023. Publiquei a conversa como fonte. Eu sei.)
\nFaz alguns anos que acompanho minha alimentação e composição corporal de forma obsessiva. Peso minha comida. Registro meus macros. Anoto cada treino. Eu sou esse cara, o que a essa altura já aceitei completamente.
\nEntão quando o Musclog começou a gerar projeções de peso, confiei nos dados. E os dados me disseram que após dois meses de superávit calórico moderado e treino consistente, eu deveria ter ganhado cerca de 2,5 kg.
\nEu tinha ganhado 1,1 kg (e sim, principalmente gordura, é o que é).
\nA princípio pensei que estava errando na contagem de calorias. Depois achei que talvez tivesse calculado meu TDEE errado (o que provavelmente também é verdade). Mas os números continuavam errados na mesma direção, consistentemente, ao longo de vários meses. Algo estava errado no próprio modelo.
\nEntão comecei a investigar. E o que descobri foi que a regra das 7700 kcal/kg - usada por basicamente toda calculadora de calorias na internet - comete um erro fisiológico enorme que eu nunca havia questionado.
\nA regra clássica das 7700 kcal/kg confunde a energia contida em um tecido com a energia necessária para construí-lo. Essas duas coisas não são a mesma.
\nQuando você olha para os modelos termodinâmicos de síntese de tecido humano, as coisas ficam interessantes:
\nTecido Adiposo (Gordura)
\nMúsculo Esquelético
\nSe você usar a regra padrão de 7700 kcal/kg para um lean bulk, seu app vai superestimar muito o quanto o usuário vai ganhar, porque construir músculo consome uma boa parte da energia no próprio processo de construção - energia que nunca vai parar dentro do tecido.
\nÉ por isso que minhas projeções estavam tão erradas. O Musclog estava assumindo que todo ganho de peso era basicamente armazenamento de gordura. Na realidade, boa parte do meu superávit estava sendo queimada como custo metabólico da construção muscular. As calorias não desapareceram - foram gastas construindo tecido novo, não preenchendo-o.
\nUma vez que entendi a distinção entre energia armazenada e custo de construção, surgiu um novo problema: de onde tiro os números reais?
\nComecei pelo ChatGPT (obviamente) - que, em minha defesa, também foi exatamente como obtive esses números em 2023, só que naquela vez colei a conversa com o ChatGPT diretamente no post do blog e considerei isso uma citação. Dessa vez, eu queria algo que pudesse rastrear de verdade até uma fonte real. Então acabei no Google Books lendo partes de The Nutritionist: Food, Nutrition, and Optimal Health, do Robert Wildman, às 23h de uma terça-feira, o que definitivamente não estava nos meus planos para a semana. Encontrei lá os detalhamentos exatos de composição de tecidos que precisava. Para as porcentagens de eficiência de síntese - 23% para proteína, ~93% para lipídios (é aqui que a turma do keto começa a ficar com raiva) - rastreei esses números de volta às análises termodinâmicas de J.P. Flatt, especificamente seu capítulo de 1978 “The biochemistry of energy expenditure”, citado como fonte fundamental em vários dos artigos mais rigorosos sobre modelagem calórica. E com tudo isso, finalmente consegui fazer a matemática eu mesmo.
\nVeja como os cálculos funcionam na prática:
\nPara músculo, 1 kg contém 200g de proteína e 50g de lipídios. A síntese proteica roda com cerca de 23% de eficiência - ou seja, são necessários ~17 kcal para incorporar 1g de proteína ao tecido (4 kcal armazenadas, 13 kcal queimadas no processo). A síntese lipídica roda com ~93% de eficiência, então cerca de 10 kcal por grama.
\nPara gordura corporal, 1 kg contém 850g de lipídios e 20g de proteína:
\nE essas são as constantes que foram parar no meu código. Também cruzei esses dados com os meus dados do trabalho anterior de rastreamento de TDEE para validar o modelo contra números reais do meu próprio corpo, o que ajudou bastante.
\nPara deixar o Musclog preciso, tive que abandonar a matemática estática e construir um modelo dinâmico. Primeiro, defini as constantes energéticas:
\nMas conhecer as constantes não é suficiente - também precisamos saber se o usuário está ganhando principalmente gordura ou músculo. É aqui que entra o P-ratio, e honestamente o P-ratio foi a coisa que mais me surpreendeu em todo esse processo de pesquisa. O conceito foi formalizado por Gilbert Forbes em seu livro de 1987 Human Body Composition e desde então foi extensivamente estudado no contexto de intervenções de superávit e déficit calórico. Eu estava assumindo que meu bulk era aproximadamente 50/50 gordura-músculo (que é a estimativa genérica para intermediários), mas a divisão real é fortemente influenciada pela experiência de treino de formas que eu não havia considerado.
\nUm iniciante - alguém no primeiro ano de musculação - pode ganhar músculo dramaticamente mais rápido em relação à gordura. Os ganhos de novato são reais e são fisiologicamente distintos do que acontece com um praticante intermediário ou avançado em superávit. Um levantador avançado em um bulk vai acabar armazenando proporcionalmente mais gordura porque o fator limitante para a síntese muscular já está próximo do seu teto genético. Que delícia.
\nEscrevi uma função auxiliar para determinar essa divisão com base no nível de experiência declarado pelo usuário:
\nAgora, em vez de dividir cegamente o superávit calórico por 7700, o Musclog calcula o custo calórico efetivo de ganhar um quilograma de peso corporal misto com base no nível de experiência do usuário:
\nPara um iniciante: (0.4 * 8840) + (0.6 * 3900) = 5.876 kcal por kg. Isso é uma diferença enorme em relação à regra genérica das 7700 kcal, e é exatamente esse tipo de lacuna que explica por que minhas projeções estavam tão consistentemente erradas.
A tela de Gerenciamento de Metas no Musclog - é aqui que o motor de projeção realmente roda. As metas calóricas e de peso que você define aqui alimentam diretamente o modelo descrito neste post.
\nA perda de peso exige uma abordagem completamente diferente, e é aqui que as coisas ficaram genuinamente complicadas.
\nQuando você está em déficit calórico, está liberando energia armazenada em vez de construir novo tecido - então o que importa agora é a densidade energética armazenada, não o custo de construção. O problema é que você não perde gordura pura. Você perde uma mistura de gordura e massa magra, e a proporção dessa mistura muda dependendo de quão magro você já está. Quanto mais magro você está, mais massa magra você perde em relação à gordura num déficit. Esse é um fenômeno bem documentado e tem implicações reais para como calcular projeções de perda de peso.
\nPara modelar isso com precisão, implementei as equações de densidade energética do artigo de 2008 de Kevin Hall “What is the required energy deficit per unit weight loss?” (publicado no International Journal of Obesity) e a curva de Forbes do livro mencionado acima. E para calcular a proporção de perda de gordura versus massa magra dinamicamente com base no percentual de gordura corporal atual, tive que implementar o ramo principal da função Lambert W em TypeScript para resolver as equações diferenciais subjacentes - uma técnica descrita no artigo de acompanhamento de Hall em 2010 “Predicting metabolic adaptation, body weight, and body fat changes in humans” no American Journal of Physiology:
\nQuero deixar claro que não derivei isso do zero - trabalhei a partir do artigo de Hall (2008) e adaptei a implementação para TypeScript. Mas validei contra dados reais das minhas próprias fases de cutting (graças à infraestrutura de rastreamento que criei em 2023), e o modelo se sustenta bem na prática.
\nCom isso, o Musclog calcula dinamicamente exatamente quantas calorias estão em um quilograma de peso perdido para um usuário específico, com base no seu percentual de gordura corporal atual. Se o usuário não souber seu percentual de gordura, o app volta com segurança para a regra clássica de ~7700 kcal/kg como base - porque alguma aproximação é melhor que nenhuma.
\nQuero ser honesto sobre as limitações aqui. Essas são estimativas em nível populacional. A variação individual na eficiência de síntese proteica muscular, ambiente hormonal, estímulo de treino, qualidade do sono e genética significa que nenhum modelo estático vai prever perfeitamente o que acontece com o corpo de uma pessoa específica.
\nOs valores de P-ratio que estou usando (0,4 / 0,5 / 0,6) são médias razoáveis da literatura, não números individualmente calibrados. Numa versão futura, adoraria calcular o P-ratio pessoal do usuário a partir dos seus dados históricos - o Musclog já tem tudo o que precisa para isso, só não está implementado ainda.
\nMas “mais preciso do que 7700 kcal/kg para tudo” é uma melhoria significativa em relação ao status quo, e as projeções ficaram visivelmente melhores desde que lancei isso.
\nConstruir side projects é divertido porque você começa pensando “vou fazer uma calculadora simples,” e uma semana depois está lendo artigos de fisiologia dos anos 70 e implementando funções Lambert W em TypeScript à meia-noite. Clássico.
\nTratando o ganho de peso como um projeto de construção caro e a perda de peso como liberação dinâmica de energia, as projeções no Musclog são muito mais precisas do que as calculadoras padrão de BMR+500 espalhadas pela web. E elas realmente bateram com meus dados do mundo real depois que acertei o modelo, o que é o resultado mais satisfatório em qualquer side project.
\nTodo esse trabalho começou com o script de TDEE com a Google Fitness API que escrevi em 2023 - se você não leu aquele e curte esse tipo de rastreamento obsessivo de fitness, vale a pena dar uma olhada.
\nSe quiser fuçar no código, o Musclog é totalmente open-source no GitHub. E se quiser usar o app de verdade, pode baixar no Google Play. Deixa um comentário se quiser conversar sobre a matemática.
\nAté a próxima!
","relatedPosts":[],"otherLanguagesUrl":[],"rss":{"title":"Por que a regra das 7700 calorias é falha (e como eu a corrigi no meu app)","description":"Por que a regra das 7700 calorias é falha (e como eu a corrigi no meu app)","date":"2026-02-12T00:00:00.000Z"},"images":["/static/9e01cdc27fc3fbd2671706b845005fe1/42a19/7700-calorie-illustration.png","../../uploads/blog/2026/03/screenshot-6.png"],"videos":[],"comments":[],"googleFormData":{},"pageType":"blogPost","categoryImage":"/categories_coding.jpg/","slug":"/2026/2026-02-12-por-que-a-regra-das-7700-calorias-e-falha-e-como-eu-a-corrigi-no-meu-app.pt-br/","locale":"pt-br","title":"Por que a regra das 7700 calorias é falha (e como eu a corrigi no meu app)","previous":{"excerpt":"I thought I had this figured out in 2023. I built a Node.js…","html":"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.
\nThen 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.
\nSo I plugged in the same logic from 2023. And the projections were consistently, confidently wrong.
\nIf 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.
\nI 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.
\nTo 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.
\nI’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.
\nSo 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.
\nI had gained 1.1 kg (and yes, mostly fat, it is what it is).
\nAt 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.
\nSo 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.
\nThe 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.
\nWhen you look at the thermodynamic models for human tissue synthesis, things get interesting:
\nAdipose Tissue (Fat)
\nSkeletal Muscle
\nIf 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.
\nThis 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.
\nOnce I understood the distinction between stored energy and construction cost, I had a new problem: where do I get the actual numbers?
\nI 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.
\nHere’s how the calculations actually work:
\nFor 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.
\nFor body fat, 1 kg contains 850g of lipids and 20g of protein:
\nAnd 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.
\nTo make Musclog accurate, I had to ditch the static math and build a dynamic model. First, I set up the energetic constants:
\n// Established thermodynamic model for human adipose tissue & skeletal muscle\r\nconst CALORIES_STORED_KG_FAT = 7730;\r\nconst CALORIES_BUILD_KG_FAT = 8840;\r\n\r\nconst CALORIES_STORED_KG_MUSCLE = 1250;\r\nconst 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.
\nA 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.
\nI wrote a helper to determine this split based on the user’s self-reported experience level:
\nexport function getGainFatFraction(liftingExperience?: LiftingExperience): number {\r\n switch (liftingExperience) {\r\n case 'beginner':\r\n return 0.4; // ~60% lean gain\r\n case 'advanced':\r\n return 0.6; // ~40% lean gain\r\n case 'intermediate':\r\n default:\r\n return 0.5; // 50/50\r\n }\r\n}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:
\nexport function getEffectiveKcalPerKgGain(liftingExperience?: LiftingExperience): number {\r\n const fatFraction = getGainFatFraction(liftingExperience);\r\n return fatFraction * CALORIES_BUILD_KG_FAT + (1 - fatFraction) * CALORIES_BUILD_KG_MUSCLE;\r\n}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.
\nWeight loss requires a completely different approach, and this is where things got genuinely complicated.
\nWhen 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.
\nTo 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:
\nfunction lambertW(z: number): number {\r\n if (z < -1 / Math.E) return NaN;\r\n if (z === 0) return 0;\r\n let w = z < 1 ? z : Math.log(z);\r\n for (let i = 0; i < 30; i++) {\r\n const ew = Math.exp(w);\r\n const f = w * ew - z;\r\n if (Math.abs(f) < 1e-10) return w;\r\n const fp = ew * (w + 1);\r\n w = w - f / fp;\r\n }\r\n return w;\r\n}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.
\nUsing 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.
\nI 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.
\nThe 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.
\nBut “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.
\nBuilding 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.
\nBy 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.
\nThis 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.
\nIf 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.
\nSee you in the next one!
","fields":{"postHashId":"Y29kaW5ndHJ1ZW51bGwyMDI2LTAyLTEyVDAwOjAwOjAwLjAwMFo=","slug":"/2026/2026-02-12-why-the-7700-calorie-rule-is-broken-and-how-i-fixed-it-in-my-app.en/","path":"/blog/coding/why-the-7700-calorie-rule-is-broken-and-how-i-fixed-it-in-my-app/","locale":"en"},"rawMarkdownBody":"\r\n\r\nI 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](/en/blog/coding/using-google-fitness-api-to-calculate-my-tdee-and-more/), 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.\r\n\r\nThen Google Fit started getting deprecated, I lost the foundation that script was built on, and I ended up building [Musclog](/en/blog/coding/musclog-leveraging-my-reactjs-experience-to-build-a-react-native-app/) - 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.\r\n\r\nSo I plugged in the same logic from 2023. And the projections were consistently, confidently wrong.\r\n\r\nIf 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](https://pubmed.ncbi.nlm.nih.gov/13594881/) 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.\r\n\r\nI 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.\r\n\r\n## When math isn't mathing\r\n\r\nTo be upfront about what's new here vs. what I [already covered in 2023](/en/blog/coding/using-google-fitness-api-to-calculate-my-tdee-and-more/): 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.\r\n\r\nI'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.\r\n\r\nSo 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.\r\n\r\nI had gained 1.1 kg (and yes, mostly fat, it is what it is).\r\n\r\nAt 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.\r\n\r\nSo 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.\r\n\r\n## The difference between *storing* and *building*\r\n\r\nThe 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.\r\n\r\nWhen you look at the thermodynamic models for human tissue synthesis, things get interesting:\r\n\r\n**Adipose Tissue (Fat)**\r\n\r\n- Fat is about 86% lipid, 5% water, and a bit of protein.\r\n- Energy stored inside 1 kg of fat: ~7730 kcal\r\n- Energy cost to build 1 kg of fat: ~8840 kcal\r\n- Efficiency: ~87%. The human body is depressingly efficient at storing excess energy as fat.\r\n\r\n**Skeletal Muscle**\r\n\r\n- Muscle is mostly water (~70%), about 24% protein, and some trace lipids.\r\n- Energy stored inside 1 kg of muscle: ~1250 kcal (water has zero calories).\r\n- Energy cost to build 1 kg of muscle: ~3900 kcal.\r\n- 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.\r\n\r\nIf 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.\r\n\r\nThis 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.\r\n\r\n## Down the rabbit hole\r\n\r\nOnce I understood the distinction between stored energy and construction cost, I had a new problem: where do I get the actual numbers?\r\n\r\nI 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](https://books.google.com) (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.\r\n\r\nHere's how the calculations actually work:\r\n\r\nFor 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.\r\n\r\n- Protein: 200 x 17 = 3400 kcal\r\n- Fat: 50 x 10 = 500 kcal\r\n- **Total to build 1 kg of muscle: 3900 kcal**\r\n\r\nFor body fat, 1 kg contains 850g of lipids and 20g of protein:\r\n\r\n- Lipids: 850 x 10 = 8500 kcal\r\n- Protein: 20 x 17 = 340 kcal\r\n- **Total to build 1 kg of fat: 8840 kcal**\r\n\r\nAnd there are the constants that ended up in my code. I also cross-referenced these against the data from my [earlier TDEE tracking work](/en/blog/coding/using-google-fitness-api-to-calculate-my-tdee-and-more/) to sanity-check the model against real numbers from my own body, which helped a lot.\r\n\r\n## Translating thermodynamics into code\r\n\r\nTo make Musclog accurate, I had to ditch the static math and build a dynamic model. First, I set up the energetic constants:\r\n\r\n```typescript\r\n// Established thermodynamic model for human adipose tissue & skeletal muscle\r\nconst CALORIES_STORED_KG_FAT = 7730;\r\nconst CALORIES_BUILD_KG_FAT = 8840;\r\n\r\nconst CALORIES_STORED_KG_MUSCLE = 1250;\r\nconst CALORIES_BUILD_KG_MUSCLE = 3900;\r\n```\r\n\r\nBut 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*](https://link.springer.com/book/10.1007/978-1-4612-4654-1) 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.\r\n\r\nA 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.\r\n\r\nI wrote a helper to determine this split based on the user's self-reported experience level:\r\n\r\n```typescript\r\nexport function getGainFatFraction(liftingExperience?: LiftingExperience): number {\r\n switch (liftingExperience) {\r\n case 'beginner':\r\n return 0.4; // ~60% lean gain\r\n case 'advanced':\r\n return 0.6; // ~40% lean gain\r\n case 'intermediate':\r\n default:\r\n return 0.5; // 50/50\r\n }\r\n}\r\n```\r\n\r\nNow, 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:\r\n\r\n```typescript\r\nexport function getEffectiveKcalPerKgGain(liftingExperience?: LiftingExperience): number {\r\n const fatFraction = getGainFatFraction(liftingExperience);\r\n return fatFraction * CALORIES_BUILD_KG_FAT + (1 - fatFraction) * CALORIES_BUILD_KG_MUSCLE;\r\n}\r\n```\r\n\r\nFor 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.\r\n\r\n\r\n\r\n*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.*\r\n\r\n## The math of losing weight (the Hall-Forbes model)\r\n\r\nWeight loss requires a completely different approach, and this is where things got genuinely complicated.\r\n\r\nWhen 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.\r\n\r\nTo 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?\"*](https://pmc.ncbi.nlm.nih.gov/articles/PMC2376744/) (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\"*](https://pmc.ncbi.nlm.nih.gov/articles/PMC2838532/) in the *American Journal of Physiology*:\r\n\r\n```typescript\r\nfunction lambertW(z: number): number {\r\n if (z < -1 / Math.E) return NaN;\r\n if (z === 0) return 0;\r\n let w = z < 1 ? z : Math.log(z);\r\n for (let i = 0; i < 30; i++) {\r\n const ew = Math.exp(w);\r\n const f = w * ew - z;\r\n if (Math.abs(f) < 1e-10) return w;\r\n const fp = ew * (w + 1);\r\n w = w - f / fp;\r\n }\r\n return w;\r\n}\r\n```\r\n\r\nI 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](/en/blog/coding/using-google-fitness-api-to-calculate-my-tdee-and-more/)), and the model holds up well in practice.\r\n\r\nUsing 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.\r\n\r\n## This still isn't perfect\r\n\r\nI 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.\r\n\r\nThe 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.\r\n\r\nBut \"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.\r\n\r\n## Conclusion\r\n\r\nBuilding 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.\r\n\r\nBy 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.\r\n\r\nThis whole line of work started with the [Google Fitness API TDEE script I wrote in 2023](/en/blog/coding/using-google-fitness-api-to-calculate-my-tdee-and-more/) - if you haven't read that one and you're into this kind of obsessive fitness tracking, it's worth a look.\r\n\r\nIf you want to poke around the code, [Musclog is fully open-source on GitHub](https://github.com/blopa/musclog-app). And if you actually want to use it, you can [download it on Google Play](https://play.google.com/store/apps/details?id=com.werules.logger). Drop a comment if you want to geek out over the math.\r\n\r\nSee you in the next one!\r\n","frontmatter":{"tags":["typescript","musclog","algorithms","fitness","nutrition","bodybuilding"],"categories":["coding"],"allowComments":true,"publishOnMedium":false,"cover":null,"date":"2026-02-12T00:00:00.000Z","id":null,"path":"why-the-7700-calorie-rule-is-broken-and-how-i-fixed-it-in-my-app","show":true,"title":"Why the 7700 calorie rule is broken (and how I fixed it in my app)","hideExcerpt":false,"subtitle":"Spoiler: your body did not read the rulebook"}},"next":{"excerpt":"Picture this: you’re in the gym. You’re between sets. You’re…","html":"Picture this: you’re in the gym. You’re between sets. You’re sweating. You have about 90 seconds before you need to grab the bar again, and you’re standing there poking at your own app like someone’s dad trying to navigate a website from 2008. Four taps to log a single set. Four taps. In an app you wrote. That you could change. And somehow, every single time, you do the four taps because there’s always something else to build first.
\nThat was Musclog. My fitness tracker. My “300 hours I’ll never get back” project that I wrote about back in 2024. It worked. My friends used it. I tracked every workout and every gram of food for months.
\nIt was also, objectively, one of the ugliest apps I had ever put on a phone.
\nI knew it. My friends knew it. The one friend honest enough to say “dude, this looks like a website” knew it and said it to my face with zero hesitation. But it worked, and for a while that was enough. “It works” is the developer’s equivalent of “it’s fine” - technically true, emotionally a complete lie you’ve agreed to live with.
\nThen the UX debt started compound-interesting its way into my life. Logging a workout felt like filing paperwork. Adding food required jumping between three different screens when it should have been one. Navigating the app in the gym, already sweating and under a time constraint, was an exercise in friction I had accidentally designed myself. I kept adding features on top of this visual chaos, which is a great way to make a hoarder’s house even harder to navigate. And not to mention the bugs, that sometimes would simply crash the app and then sit on Sentry, unsolved.
\nSomething had to change. And by “something” I mean everything.
\nThe original app was built with react-native-paper, which is a perfectly decent library. The problem wasn’t react-native-paper. The problem was me. I slapped components together in whatever order made sense at the time, picked colors by vibes, and shipped without any real design system. No spacing scale. No semantic color palette. Just pure developer instinct applied directly to a UI, which, as it turns out, produces exactly the kind of app I ended up with.
\nThe same concept looked different across three screens because each screen was built at a different point in my understanding of the app. Primary buttons had different heights depending on where you found them. Cards had three different corner radii that I had presumably chosen with great intention and then completely forgotten about. Colors were hardcoded everywhere. The whole thing was held together with confidence and duct tape.
\nThe migration plan: rip out react-native-paper, replace it with NativeWind (Tailwind CSS for React Native), and build a real design system from scratch. Simple. Straightforward. Completely insane given the size of the codebase at this point.
\nI went and did it anyway, because I have no self-preservation instinct when it comes to side projects.
\nI had been watching Google Stitch since it launched. The short version: it’s an AI tool that generates mobile app UI from prompts and screenshots. You describe the aesthetic you want, drop in reference screens, and it generates coherent React components. For a developer who has genuinely tried to learn design three separate times and failed each time for fundamentally different reasons, this felt like cheating in the best possible way.
\nI fed it the existing Musclog screens and described what I wanted: dark theme, fitness and performance aesthetic, something that felt like looking at serious data rather than a to-do list. I wanted it to feel like the dashboard of something that means business, not like a wellness app that’s going to suggest you “take a breath” before logging your deadlift.
\nI iterated for a full weekend and landed on what Stitch calls it the “Kinetic Depth” design system. Deep greens for the surfaces (swampGreen #0a1f1a for the background, charcoalGreen #141a17 for cards, gunmetalGreen #1a2420 for elevated elements). Indigo-to-emerald gradients for primary actions and progress indicators. Large, clear numbers for the things that actually matter: weight lifted, reps completed, calories in.
The unexpected part was how much this process forced me to think clearly about the product itself. To generate a good screen in Stitch, I had to articulate what that screen was for before I could describe what it should look like. That process exposed UX problems that had nothing to do with colors. One step in the workout logging flow existed purely because of a technical limitation I had worked around with UI instead of fixing the actual problem. Fixed. Pretended it never happened. Fixed, then refactored the underlying service so it could never come back.
I Stitch also wrote a proper design document for the first time in this project’s life: surface colors with names, semantic colors for macros (protein is always indigo #6366f1, fat is always amber #f59e0b, carbs are emerald #10b981, fiber is pink #ec4899), spacing scale at 4/8/12/16/20/24/32px, border radius standards at 12px for inputs and 16px for primary cards. Things I should have defined before writing a single line of UI code. The “just ship it” bill arrived, as it always does, with interest.
Since I was already burning the UI down to the studs, I took the opportunity to tighten the underlying architecture too. This is the part where most people’s eyes glaze over, but if you’re building something with local-first data storage in React Native, some of these decisions might save you time.
\nMusclog uses WatermelonDB for local storage. Not raw SQLite, not MMKV, not AsyncStorage. WatermelonDB sits on top of SQLite on native and LokiJS on web, and it gives you a model layer with reactive queries. When data changes, any component observing that query re-renders automatically. No manual state sync. No “did I remember to refresh the list after saving?” bugs. The same codebase runs on Android and in the browser without touching the data layer, which matters when you want to test something quickly without spinning up a device.
\nThe layered structure goes: schema definition at the bottom, then models, then services that handle CRUD and business logic. Non-database services (AI, notifications, Health Connect sync) live separately in their own services/ dir. Every write goes through database.write(async () => { ... }). No exceptions. Nested write blocks cause deadlocks in WatermelonDB, and they’re a pain to debug, so the rule is simple: never nest them, and if you find yourself wanting to, you’ve designed something wrong upstream.
Here’s what that looks like in NutritionCheckinService.ts when creating a batch of weekly check-ins:
static async createBatch(\r\n nutritionGoalId: string,\r\n checkins: NutritionCheckinInput[]\r\n): Promise<NutritionCheckin[]> {\r\n return await database.write(async () => {\r\n const collection = database.get<NutritionCheckin>('nutrition_checkins');\r\n\r\n const preparedRecords = checkins.map((data) =>\r\n collection.prepareCreate((record) => {\r\n record.nutritionGoalId = nutritionGoalId;\r\n record.checkinDate = data.checkinDate;\r\n record.targetWeight = data.targetWeight;\r\n record.status = data.status ?? 'pending';\r\n })\r\n );\r\n\r\n await database.batch(...preparedRecords);\r\n return preparedRecords;\r\n });\r\n}The prepareCreate + database.batch() combo is how WatermelonDB handles multiple inserts atomically without multiple round trips. One write() block, one batch, done. You never call another service’s database.write() from inside here, because that’s how you get a deadlock at 11pm that somehow only reproduces on device.
Same props interface, same behavior, different rendering backends. The Expo bundler resolves Volume tracking works the same way at the infrastructure level, except the interesting problem there is the math. Musclog tracks volume as estimated one-rep max, not raw weight x reps, because 5 reps at 80kg and 12 reps at 60kg are different training stimuli that produce the same number on a naive volume chart. The problem is there’s no single accepted 1RM formula. Brzycki, Epley, Lander, Mayhew - they all give you a slightly different number for the same set, and the research doesn’t pick a clear winner. So Musclog runs all seven and averages them: The Right. The redesign was the visible part of this update. The more significant part, at least from a “is this app actually useful” standpoint, was completely rebuilding how food tracking works. The original version relied heavily on the nutritional information coming from Health Connect. If you didn’t have another app to do the nutrition tracking, you were left in the dumpster. That’s acceptable for a weekend project. It’s not acceptable for an app people use daily to track calories, protein, carbs, fat, and 40+ micronutrients across multiple meals. To my genuine surprise, I discovered that high-quality food data doesn’t actually live behind a corporate gatekeeper. There are massive, free public APIs - like the USDA and Open Food Facts - that provide everything from deep micronutrient breakdowns to global barcode lookups without charging a cent. Finding these was a major “aha!” moment: if the data is public and the processing happens right on your device, there is absolutely no technical justification for nutrition tracking to be a subscription-based SaaS. Most “premium” apps are essentially charging you a monthly fee to act as a middleman for data they don’t even own, but that’s a spicy discussion I’ve saved for another time.\r\nMusclog now connects to two real food databases. USDA FoodData Central is the US Department of Agriculture’s public nutritional database. Hundreds of thousands of foods, from branded products to raw ingredients, with detailed macro and micronutrient breakdowns. It’s government data, it’s free, and the API doesn’t require a credit card, which as you’ll see is a non-trivial consideration for me. Coverage for American and global branded products is genuinely solid. This is the backbone of the search. The USDA identifies nutrients by numeric codes, so mapping them to something human-readable requires a lookup layer. Here’s what the mapper looks like in practice: The double Open Food Facts is a community-driven database of food products from around the world. Think Wikipedia but for nutrition labels: anyone can add a product, the data is open under the ODbL license, and because it’s globally crowdsourced it covers products that the USDA database mostly ignores, like whatever fermented dairy thing is in the Dutch supermarket five minutes from my apartment. When your primary nutrition database assumes you exclusively eat American products and you live in the Netherlands, you start appreciating open global datasets very quickly. Querying it is refreshingly simple for something this comprehensive: Both searches run in parallel (with abort controllers so stale requests don’t race each other) and the results merge into a single unified list. The user picks from local foods, Open Food Facts results, and USDA results all at once without knowing or caring which backend each came from. Between the two, you can search for pretty much any food and get real nutritional data without typing anything manually. And because Musclog now tracks over 40 micronutrients beyond the standard macros, you can actually see things like your magnesium intake, your zinc levels, your vitamin D. Turns out this matters once you start looking at what you’re consistently missing. For me it’s magnesium. It’s always magnesium. For when you can’t scan anything because you’re eating at a restaurant or staring at a plate of “it’s probably chicken with some sauce,” there’s OCR label scanning (tesseract.js on web, rn-mlkit-ocr on native) and AI-based photo estimation, which I’ll get to in a second. The OCR follows the same dual-file pattern as the charts. Identical function signature, different engine, bundler picks the right one at build time: ML Kit runs on-device and is fast. Tesseract.js boots and kills a full worker for every scan, which is not elegant, but it works offline and nothing leaves the browser. The language pack covers English, Spanish, Portuguese, Dutch, German, and French. I live in the Netherlands, I’m Brazilian, and I was not shipping a grocery label scanner that choked on Dutch cheese packaging. The original chatbot was called Chad. Yeah I know, not very creative, but I was focussing more on “shipping” features than making them appealing. And that’s ok, right, Chad? It’s now called Loggy, it supports both OpenAI and Google Gemini, and it’s actually connected to your data in a meaningful way. When you ask Loggy something, it knows who you are: your recent workouts, your nutrition logs, your weight trends, your current goals. “Was my training volume last week on track?” gets a real answer based on real data, not a generic tip about progressive overload you’ve already read fifteen times. The structured output layer was one of the more interesting technical problems here. Getting LLMs to reliably output structured data (instead of prose that looks like structured data but breaks your JSON parser) requires care. The The function itself is simple enough that I almost didn’t write it down: Recursively walks every nested object in the schema and slaps The photo analysis feature is the one that makes new users do a double-take. Take a photo of your meal, Loggy estimates portion sizes and nutritional content. It’s not replacing a food scale for precision tracking, but for eating out or for days when you genuinely can’t scan anything, it gets you in the right ballpark fast. The flow sends the image to the model with a structured schema for the response, extracts the estimates, and then makes you confirm before logging. That last step matters: the AI proposes, you decide. System prompts live in Every week, Musclog runs an automated analysis of your 7-day rolling averages for weight, caloric intake, and activity. You get a status: On Track, Ahead, or Behind. If your numbers are diverging from your targets, it can recalculate your nutrition goals based on what actually happened rather than locking you into a plan that clearly isn’t matching reality. The core of it is The The TDEE calculation is empirical rather than formula-based. Musclog looks at your actual weight change over time combined with your actual logged calorie intake and works backwards to estimate your real maintenance calories. If you’ve been eating 2,200 calories a day and losing 0.3kg per week, the math tells you something about your actual metabolism that the Harris-Benedict formula never will, especially if your activity level doesn’t fit neatly into “sedentary” or “moderately active” or whatever vague category you picked during onboarding. The function that does this lives in The asymmetry between building fat (8840 kcal/kg) and burning it (7730 kcal/kg) is real. Thermodynamic efficiency isn’t 100%, so creating new tissue costs more than what ends up stored. Same principle applies to muscle. If you just hardcode 7700 and move on you get something that’s approximately right, but you’re averaging away the exact signal you built the whole check-in system to find. This is not a flashy feature. You don’t notice it until the end of the week. But having an app that notices “you’ve been under your calorie target all week and your weight still hasn’t moved, let’s figure out why” is exactly the kind of insight I was building toward when I started this project. I just didn’t know it at the time. I thought I was building a workout logger. Home screen widgets for quick logging and daily summaries. A menstrual cycle tracker with workout intensity recommendations by phase, because assuming a male-only user base is The export feature sounds boring until your phone dies, and you don’t have it. At that point you’re simultaneously grateful you built it and slightly furious at past-you for not testing the import path more thoroughly. Ask me how I know. I want to say something about the fitness app market, because I have been holding this in for roughly two years and this is my blog. The story repeats on a schedule you can set your watch to: app launches free, gets users, introduces a premium tier, gradually migrates core features behind the paywall, raises prices, users complain on Reddit, nothing changes. I’ve watched this happen to apps I genuinely liked using. MyFitnessPal went from actually good and free to a subscription where setting your own macro targets costs money. Other apps introduced “premium food databases” that took away the useful thing and sold it back monthly. One app I used for a while moved the progress charts behind a paywall. The progress charts. In a fitness tracking app. The one feature that shows whether the app is even working. “But without subscription revenue, how do you keep the lights on?”\r\nThe lights are a charging cable and cost zero per month. Next question. I understand the economics. Servers cost money. Engineering teams cost money. Building a sustainable product business is genuinely hard and someone has to pay for it. Fine. But Musclog doesn’t have servers. There’s no cloud infrastructure. No database I’m paying to host somewhere. Your data lives on your phone. The food databases I use are public and free. The AI features, if you use them, talk directly to OpenAI or Google using your own API key: you pay them, no middleman, no cut. The app is free on Google Play and open source on GitHub. This isn’t a principled stand against capitalism. It’s a design decision that makes sense for what this actually is: a personal tool I built for myself and then shared with other people. The architecture I chose naturally creates no server costs, which means I have no financial pressure to monetize, which means users have no reason to be suspicious about what I’m doing with their data. Because I’m not doing anything with their data. It’s on their phone. The offline-first design is deliberate for the same reason. Weight history, body composition, what you eat, your menstrual cycle, your workout history: none of this should live on a stranger’s server by default. Most fitness apps don’t explain clearly what they do with that data because a transparent answer would be unpopular. Musclog keeps everything local. The only data that ever leaves your device is what you explicitly send to the AI, and only when you choose to use that feature. There’s a whole population of people training in gyms with patchy WiFi, in basements, in garages, in parks, who have never once had Musclog fail because it needed to call home. That matters to me more than a monthly recurring revenue number. Onboarding is the weakest part of the app right now. Musclog is significantly more useful the more data it has, but the new user experience is still too close to “here’s the entire app, figure it out.” I want to build a proper onboarding flow that gets someone set up with their goals, their first workout template, and their first food log in under five minutes. You shouldn’t need 500 hours of context to get value from day one. BLE device support for smart scales is also on the list. Manually entering weight and body fat every day is fine. Having the scale send it to the app automatically when you step on it is better, and the infrastructure isn’t that complex. It’s mostly a matter of getting my hands on hardware to test against, which is a very solvable problem and definitely something I’ll do as soon as I finish the seventeen other things I’ve already started. Fair question. The short answer is: I have no idea. The longer answer is more interesting. The code is open source under Attribution-NonCommercial-NoDerivatives 4.0 International. You can read it, fork it for personal use, learn from it. You just can’t ship a product built on it without talking to me first, because Musclog is a proprietary brand that I own, and because the five hundred hours of work behind it represent something north of €25000 in European software engineering salaries. I’m not running a charity. I’m running a side project that hasn’t asked you for money yet. If that ever changes, here’s my promise: I won’t do the subscription thing. If Musclog ever costs money, it’ll cost money once. You pay the price of a coffee, the app is yours, forever. No recurring fees. No “your premium plan has been paused.” The good old model, the one the App Store basically killed. The thing pushing me closest to that scenario right now is iOS. My girlfriend wants it on iPhone. Some close friends want it on iPhone. I’ve been hearing “just put it on the App Store” for months as if it’s a trivial thing. The Apple developer program costs 100 USD a year. Per year. Not once. Every year. Apple built a SaaS out of the right to distribute software, and I say this as someone who thinks Google Play’s one-time 35 USD fee is how it should work everywhere. So yes, if Musclog ever lands on iOS, it’ll probably have a price tag, because I am not paying a 100 USD annual toll to Apple out of goodwill. For now: Android, free, no plans to change that. So grab it while it’s free, because once you download it on Google Play, it’s yours forever. Even if you didn’t pay for it. Especially if you didn’t pay for it. Two years, two versions, 500 hours. Musclog finally looks like something I don’t mentally apologize for before showing to someone. The redesign cleared years of “just ship it” UI debt, and doing it properly forced me to think about the product in ways I should have been thinking about since the beginning. Turns out design systems exist for good reasons and not just to give designers something to talk about in Figma. It’s free. It’s open source. It doesn’t have your data. It works in airplane mode. Real food databases. AI that actually knows who you are. Automated weekly check-ins. And a dark green color scheme I’m genuinely proud of, even if an AI tool did most of the visual heavy lifting. If you want to try it: Google Play. If you want to see how it’s built or contribute something: github.com/blopa/musclog-app. Lift, Log, Repeat. See you in the next one!LineChart to the .web.tsx file on web and the .tsx file everywhere else. Zero conditionals in the component that actually uses it.\n// utils/workoutCalculator.ts\r\nexport function calculateAverage1RM(weight: number, reps: number, rir: number = 0): number {\r\n const formulas: FormulaType[] = [\r\n 'Epley', 'Brzycki', 'Lander', 'Lombardi', 'Mayhew', 'OConner', 'Wathan',\r\n ];\r\n let total1RM = 0;\r\n let validFormulas = 0;\r\n\r\n formulas.forEach((formula) => {\r\n const oneRM = calculate1RM(weight, reps, formula, rir);\r\n if (oneRM !== null) {\r\n total1RM += oneRM;\r\n validFormulas++;\r\n }\r\n });\r\n\r\n return validFormulas > 0 ? total1RM / validFormulas : 0;\r\n}rir parameter is Reps in Reserve: if you stopped at 8 but had 2 more in the tank, rir = 2 adjusts the estimate upward to reflect what you could actually lift. Logging your RIR is optional. The kind of person who built their own fitness app and tracks everything in a spreadsheet is usually also the kind of person who tracks their RIR. I’m not saying it’s me. It’s me.Wait, what about the actual food data?
\nUSDA FoodData Central
\n\n// utils/usdaMapper.ts\r\nexport function mapUSDAFoodToUnified(food: USDAFood): UnifiedFoodResult {\r\n const nutrients = food.foodNutrients;\r\n\r\n // USDA uses nutrient number codes - 1008/208 is energy, 1003/203 is protein, etc.\r\n const calories = mapUSDANutritient(nutrients, '1008') ?? mapUSDANutritient(nutrients, '208');\r\n const protein = mapUSDANutritient(nutrients, '1003') ?? mapUSDANutritient(nutrients, '203');\r\n const carbs = mapUSDANutritient(nutrients, '1005') ?? mapUSDANutritient(nutrients, '205');\r\n const fat = mapUSDANutritient(nutrients, '1004') ?? mapUSDANutritient(nutrients, '204');\r\n const fiber = mapUSDANutritient(nutrients, '1079') ?? mapUSDANutritient(nutrients, '291');\r\n\r\n return {\r\n id: String(food.fdcId),\r\n name: food.description,\r\n brand: food.brandOwner,\r\n calories: calories !== undefined ? Math.round(calories) : undefined,\r\n protein, carbs, fat, fiber,\r\n source: 'usda',\r\n };\r\n}?? fallback exists because USDA has two different nutrient numbering schemes depending on the data type (Foundation Foods vs. Branded Foods). Both map to the same output shape.Open Food Facts
\n\n// hooks/useUnifiedFoodSearch.ts\r\nconst url = `https://world.openfoodfacts.org/cgi/search.pl` +\r\n `?search_terms=${encodeURIComponent(query)}` +\r\n `&json=1` +\r\n `&page_size=20` +\r\n `&fields=code,product_name,brands,nutriments,serving_size,image_url`;\r\n\r\nconst response = await fetch(url, { signal: abortController.signal });\r\nconst result = await response.json();\r\n\r\nconst products = result.products.filter(\r\n (product: SearchResultProduct) => getProductName(product)\r\n);\n// utils/ocr.ts - native (Google ML Kit, runs on-device)\r\nimport { recognizeText } from 'rn-mlkit-ocr';\r\n\r\nexport async function performOcr(imageUri: string): Promise<string | null> {\r\n const result = await recognizeText(imageUri);\r\n const text = result.text.trim();\r\n return text.length > 0 ? text : null;\r\n}\r\n\r\n// utils/ocr.web.ts - web (Tesseract.js, runs entirely in the browser)\r\nimport { createWorker } from 'tesseract.js';\r\n\r\nconst OCR_LANGS = 'eng+spa+por+nld+deu+fra';\r\n\r\nexport async function performOcr(imageUri: string): Promise<string | null> {\r\n const worker = await createWorker(OCR_LANGS);\r\n const { data: { text } } = await worker.recognize(imageUri);\r\n await worker.terminate();\r\n return text.trim() || null;\r\n}The AI coach grew up
\nmakeSchemaStrict utility in utils/coachAI.ts takes any JSON schema and enforces additionalProperties: false on every nested object while marking all fields as required. This goes into the OpenAI function calling config and tells the model “return exactly this shape or fail cleanly.” It makes the difference between a feature that works 95% of the time and one that actually works.\n// utils/coachAI.ts\r\nfunction makeSchemaStrict(schema: any): any {\r\n if (schema.type === 'object') {\r\n const properties = schema.properties ? { ...schema.properties } : {};\r\n\r\n Object.keys(properties).forEach((key) => {\r\n properties[key] = makeSchemaStrict(properties[key]);\r\n });\r\n\r\n return {\r\n ...schema,\r\n properties,\r\n additionalProperties: false, // OpenAI requires this for strict mode\r\n };\r\n }\r\n\r\n if (schema.type === 'array' && schema.items) {\r\n return { ...schema, items: makeSchemaStrict(schema.items) };\r\n }\r\n\r\n return schema;\r\n}additionalProperties: false on it. Without this, OpenAI’s strict function calling rejects the schema entirely. With it, the model is constrained to exactly the shape you defined. No surprise extra keys. No fields that exist in one response but not another. The AI proposes, the schema enforces.utils/prompts.ts and pull in custom instructions from the ai_custom_prompts table, so the AI behavior is configurable without touching code.Weekly check-ins: the feature I’m most proud of
\ngetCheckinMetrics, which takes a check-in record and pulls all the data from the 7-day window ending on that date:\n// database/services/NutritionCheckinService.ts\r\nstatic async getCheckinMetrics(checkin: NutritionCheckin): Promise<CheckinMetrics> {\r\n const periodEnd = checkin.checkinDate;\r\n const periodStart = periodEnd - 7 * 24 * 60 * 60 * 1000;\r\n\r\n // Pull all weight measurements for the 7-day window\r\n const weightMetrics = await database\r\n .get<UserMetric>('user_metrics')\r\n .query(\r\n Q.where('type', 'weight'),\r\n Q.where('date', Q.between(periodStart, periodEnd)),\r\n Q.where('deleted_at', Q.eq(null)),\r\n Q.sortBy('date', Q.asc)\r\n )\r\n .fetch();\r\n\r\n // Decrypt each value (weights are AES-encrypted in the DB)\r\n const decryptedWeights: number[] = [];\r\n for (const metric of weightMetrics) {\r\n const { value } = await metric.getDecrypted();\r\n decryptedWeights.push(value);\r\n }\r\n\r\n const avgWeight = decryptedWeights.length > 0\r\n ? decryptedWeights.reduce((a, b) => a + b, 0) / decryptedWeights.length\r\n : checkin.targetWeight;\r\n\r\n // How far is the actual average from where we expected to be?\r\n const trend = avgWeight - checkin.targetWeight;\r\n\r\n // Nutrition: group logs by day, calculate average calories and consistency\r\n const nutritionLogs = await database\r\n .get<NutritionLog>('nutrition_logs')\r\n .query(Q.where('date', Q.between(periodStart, periodEnd)), Q.where('deleted_at', Q.eq(null)))\r\n .fetch();\r\n\r\n const caloriesByDay = new Map<number, number>();\r\n for (const log of nutritionLogs) {\r\n const snapshot = await log.getDecryptedSnapshot();\r\n const dayKey = Math.floor(log.date / (24 * 60 * 60 * 1000));\r\n caloriesByDay.set(dayKey, (caloriesByDay.get(dayKey) ?? 0) + snapshot.loggedCalories);\r\n }\r\n\r\n const consistency = Math.round((caloriesByDay.size / 7) * 100); // % of days with logs\r\n // ...and so on for workouts, body fat, active minutes\r\n}trend is the key number: positive means you’re heavier than the target predicted, negative means you’re ahead. Combined with consistency (what percentage of the 7 days you actually logged food), the service can infer whether the variance is real or just missing data.utils/nutritionCalculator.ts. The logic is straightforward; the constants are not:\n// utils/nutritionCalculator.ts\r\nexport const calculateTDEE = (params: TDEEParams): number => {\r\n const { totalCalories, totalDays, initialWeight, finalWeight,\r\n initialFatPercentage, finalFatPercentage, bmr, activityLevel } = params;\r\n\r\n // Path 1: real tracking data exists - derive TDEE from the First Law of Thermodynamics\r\n if (totalDays && totalCalories && initialWeight && finalWeight) {\r\n const weightDifference = finalWeight - initialWeight;\r\n\r\n // Split weight change into fat vs lean mass.\r\n // Exact when we have body fat % on both ends; Hall/Forbes curve estimate otherwise.\r\n let fatDifference: number;\r\n let leanDifference: number;\r\n\r\n if (initialFatPercentage !== undefined && finalFatPercentage !== undefined) {\r\n const initialFatMass = (initialFatPercentage * initialWeight) / 100;\r\n const finalFatMass = (finalFatPercentage * finalWeight) / 100;\r\n fatDifference = finalFatMass - initialFatMass;\r\n leanDifference = weightDifference - fatDifference;\r\n } else {\r\n const comp = getWeightChangeComposition(initialWeight * 0.25, weightDifference);\r\n fatDifference = comp.fatChangeKg;\r\n leanDifference = comp.leanChangeKg;\r\n }\r\n\r\n // Building vs burning fat and muscle have different thermodynamic costs.\r\n // These are not interchangeable constants - they're separate measured values.\r\n const leanCalories = leanDifference > 0\r\n ? leanDifference * CALORIES_BUILD_KG_MUSCLE // 3900 kcal/kg to build\r\n : leanDifference * CALORIES_STORED_KG_MUSCLE; // 1250 kcal/kg stored\r\n\r\n const fatCalories = fatDifference > 0\r\n ? fatDifference * CALORIES_BUILD_KG_FAT // 8840 kcal/kg to build\r\n : fatDifference * CALORIES_STORED_KG_FAT; // 7730 kcal/kg stored\r\n\r\n // TDEE = (energy consumed − energy locked in tissue changes) / days\r\n return Math.round((totalCalories - (fatCalories + leanCalories)) / totalDays);\r\n }\r\n\r\n // Path 2: no history yet - fall back to BMR x activity multiplier\r\n if (bmr && activityLevel) {\r\n return Math.round(bmr * ACTIVITY_MULTIPLIERS[activityLevel]);\r\n }\r\n\r\n return 0;\r\n};The other stuff I quietly shipped
\na reasonable starting point not ok so Musclog do not use gender to infer menstrual cycle data. Health Connect integration for syncing weight, nutrition, and exercise data with other Android health apps. Full data export as encrypted (or unencrypted) JSON. Import from JSON for moving between devices without losing your history.Why your fitness app subscription is someone else’s problem
\n\n
\nWhat’s next
\nWill it be free forever?
\nConclusion
\n