Meal Planner: Because Training Was Never the Hard Half

At some point I decided I was done treating my health as something I’d get around to eventually. Not a New Year’s resolution, not a phase — an actual decision, the kind you have to keep making every day for it to mean anything. Training was never actually the hard part of that. Eating on purpose, every day, for however many people were around the table that week, on a real budget of carbs and macros and time — that’s what I kept failing at with spreadsheets and good intentions. So I built a tool for it: something that could plan real weeks out of the roughly hundred recipes I actually cook, hit the numbers I was aiming for, and hand me a shopping list at the end of it.

The detail I’m proudest of is how it handles leftovers, because it’s the same instinct that shows up everywhere I build things: don’t store what you can just compute correctly when you need it. A recipe scaled for one person often covers more than one day, and exactly how many depends on how many people are eating that week, which changes constantly in a real household. Instead of storing a number that would quietly go stale the first time that changed, the planner works it out fresh every time. That decision paid for itself later without my having to think about it twice: when I added a “just fill my week for me” button, it reused the exact same logic that fills a single day, in a loop. One correct idea, reused, instead of a second system I’d eventually have to keep in sync with the first by hand.

I also learned, the uncomfortable way, what happens when you don’t plan for your own data changing under you. Early on, my recipe list got reshuffled during an unrelated change, and I realized that if any saved week had been remembering meals by their position in that list, every plan I’d ever saved would have silently pointed at the wrong food. Nothing broke that time, but it was close enough that I rebuilt how saved weeks work — each one now keeps its own permanent copy of what it actually needs, so a week I planned six months ago still tells the truth today, no matter what I’ve changed in my recipe list since.

And when the data genuinely didn’t have an answer, I let it say so instead of guessing. My recipes don’t record quantities, only ingredients, so the shopping list doesn’t pretend to know how many eggs to buy. It just tells me how many recipes that week call for eggs. Less impressive to look at. But it’s not lying to me while I’m standing in a grocery store trying to actually follow through on the plan, which is the only thing that was ever supposed to matter.

I don’t think this tool is interesting because of what framework it’s written in. It’s interesting to me because I built it under the same rigor I’d bring to anything, for an audience of exactly one person whose trust I genuinely could not afford to lose, because that person is me, in the middle of trying to change something real about how I live. I still write the decision down before I write the code, not because a design doc is impressive, but because it’s the only way I’ve found to catch myself lying to myself about why I’m building something a certain way. I still do only the engineering the goal actually calls for, and skip the rest, because effort spent on a problem that doesn’t exist is effort I don’t have left for the problem that does. That discipline isn’t something I put on for a code review. It’s the same discipline that got this tool built, and so far, kept a promise.