test the habit before you build the tool

I wanted a meal tracker on this site — daily macros against targets, with the visual “am I on track” read. The engineering half was nearly free: an encrypted store I had already built five times, a page, four bars. That is exactly why it was dangerous to start there. Building the easy half first would have produced a finished tracker and no evidence that I would use it.

The real risk was data entry. Steps cost me zero entries — a phone pushes them. The gym log costs about ten entries three times a week, all numbers I already know. Food is three to six entries every day, each needing a figure I don’t hold in my head. That gap is what kills food trackers by week two; the incumbents’ moat is their food database, not their interface. And this site never calls a model, so a lookup was not going to be how I closed the gap.

So I ran the habit for a week with no tool: meals written into a journal by hand, deliberately without chasing the numbers, because hunting for macros would have tested the wrong thing and given a false negative on the habit itself. The week held. It also turned out to be the design input — the foods that appeared over and over became the seed of a personal food library, so a meal is a food times a quantity rather than four numbers typed. The tool that got built afterwards was the smallest one the week justified, and it has been used every day since — which the week predicted and the code could not have.