“Protein first, calories second” is good advice for a person. Hit your protein and a lot else falls into place: you are fuller, you keep more muscle in a deficit, and the rest of the day has less room for food that does nothing for you.
It is terrible advice for software. An app cannot treat calories as a secondary concern, because a plan that hits your protein and misses your energy target by four hundred calories is not a plan, it is a weight change you did not ask for. Both have to land.
Which leads to a question that sounds trivial and is not: where does a calorie number come from?
Two answers, and they disagree
You can get the calories in 100 g of food two ways.
- Read the calorie column in a nutrition database.
- Compute it from the macros — 4 kcal per gram of protein, 4 per gram of carbohydrate, 9 per gram of fat.
These should match. Across our own food table, they systematically do not. Twenty-one of twenty-nine foods have a calorie column below what their own macros imply:
| Food | Calorie column vs. its own macros |
|---|---|
| Spinach | 22% lower |
| Broccoli | 21% lower |
| Cucumber | 17% lower |
| Banana | 10% lower |
| Dates | 10% lower |
| Almonds | 7% lower |
There are real reasons for the gap — fibre is counted as carbohydrate but is not fully metabolised, and food labels use adjusted energy factors rather than a flat 4/4/9. The database is not wrong. It is answering a slightly different question.
The bug
We let both methods into the app. Per-meal calorie budgets were derived one way; the totals that were checked against those budgets were computed the other.
The result was a plan that could hit every single macro budget exactly and then be rejected for being too low in calories. Vegetable-heavy menus failed most, because vegetables are where the two methods diverge most. It read as a generator problem for a while. It was an arithmetic problem, in two places that each looked right on its own.
Two correct methods for the same quantity, used in two places, is one bug waiting for a plan that leans on the difference.
What we do now
Calories are computed from macros. Everywhere. Budgets, meal totals, the saved plan, the dashboard you look at while ticking things off — all 4P + 4C + 9F, with no exceptions and no second path through the code.
The calorie column stays in the table for two narrow jobs: display, and a sanity check when a new food is looked up. If a food arrives claiming macros that are wildly out of step with its own stated calories, something is wrong with the lookup and we reject it rather than quietly planning around it.
One consequence worth knowing as a user: Protn’s calorie figure for a vegetable-heavy meal reads slightly higher than a label would. It is internally consistent, which is what matters when every number on screen has to agree with every other one.
The point
Protein first, yes. But an app that quietly runs two incompatible definitions of a calorie will hand you a plan that passes all of its own checks and is still wrong, and you will have no way of telling. One definition, used everywhere, is less clever and far more trustworthy.
More on how much protein to aim for, or how Protn builds the menu.