Don’t predict what nobody has eaten yet.

At nine in the morning, an honest calorie tracker says something useless. We tried to fix that with a projection, shipped it, and then took it out again. This is why.

The eight o’clock problem

The arithmetic underneath any calorie app is a subtraction: what you have burned, less what you have eaten. Do it at nine in the morning on an ordinary profile with nothing logged, and it says you are around six or seven hundred calories down. Do it before breakfast and it is worse.

Technically that is correct. Your body has been spending energy all night and you have not eaten since yesterday. It is also completely useless as guidance, because the number is not about your day — it is about the fact that your day has not happened yet. Watch it for a week and you learn to ignore it until the afternoon, at which point the app has trained you not to look at the one thing it exists to show.

So it is very tempting to project. Take the day’s expected burn, take the pace at which the user seems to be eating, extrapolate both to midnight, and show where the day is heading. The number is stable from breakfast onward. It looks like guidance. We built exactly that, and for a while the app’s headline figure was a forecast.

Two extrapolations that are not alike

A projection to midnight is really two guesses added together, and it is worth separating them, because they are not the same kind of guess at all.

That second row is the whole problem. If you extrapolate intake from the pace of logging, then a morning where the user simply hasn’t opened the app yet becomes a prediction that they will eat very little all day. The forecast quietly turns “nothing logged” into “nothing will be eaten”, and the projected deficit comes out large and encouraging.

You can patch around this. We tried: converge the estimate as the day fills in, weight it by how far through the eating window you are, hand over to real numbers by evening. All of that works, in the sense that the number becomes less wrong. None of it fixes the actual defect, which is not accuracy.

The real defect: nobody could check it

Here is the test that ended the argument. Look at the headline figure and ask: can a person work out where it came from using only what is on the screen?

With a projection, no. The number was a blend of a plan, an observed pace, a time-of-day weighting and a convergence rule, and none of those four things were visible. It could not be checked, only trusted. When it disagreed with a user’s sense of their own day, there was nothing for them to inspect — just a figure and an implicit ask to believe it.

For most apps that is an acceptable trade. For this one it was disqualifying, because the entire argument of the product is that every figure says where it came from. We had built, as the single most prominent number in the app, the one figure that couldn’t.

What replaced it

The headline went back to the subtraction, and stayed there:

balance = burned so far − eaten so far

Two measured figures and their difference, and nothing else. The fix for “this number is meaningless at 9am” was not to make the number cleverer. It was to put its two inputs directly underneath it, each against what the day is aiming at:

Now nine in the morning reads something like 670 / 2 182 burned against 0 / 1 732 eaten. The balance is large, and the pair underneath says plainly why it is large: the day is a third done and no food has been recorded. Nobody needs a caveat, because the caveat is the data.

The plan did not disappear. It stopped being a hidden term inside the result and became the denominator each figure is read against — visible, checkable, and doing the same job honestly.

Where extrapolation survived

One projection is still in there, and the distinction is the point of this whole piece. Expected burn by midnight — the denominator in the first row above — is an extrapolation. It is allowed to be, because burn is a physical rate: resting energy accrues around the clock, and everyday movement can be paced from what has happened so far.

But notice what it is used for. It is a denominator, not the headline. It sits on screen, labelled as an estimate, next to the measured figure it contextualises. It is never blended into the result where it cannot be seen. An estimate in the open, doing a small job, is a completely different object from an estimate hidden inside the number everybody reads first.

The general rule

If you are building anything that measures a person’s day, the distinction worth stealing is this one:

• Some quantities accrue physically. They happen whether or not your software is watching. Extrapolating them is modelling.
• Some quantities accrue only when recorded. Your data is a record of somebody’s attention, not of the world. Extrapolating them is inventing.

Steps, heart rate, energy expenditure, time elapsed: the first kind. Meals, expenses, symptoms, habits, anything with a manual entry form: the second. The failure mode is always the same, and it is always flattering — silence gets read as zero, zero looks like progress, and the user is congratulated for not typing.

A tracker that is wrong in a comforting direction is worse than one that is briefly useless in the morning. Deleting a feature you shipped is not a pleasant afternoon, but it was the right call, and the thing that replaced it is smaller, plainer and impossible to argue with.