When the first hypothesis is wrong, track better data.
I needed a way to compare meals, symptoms, stress, and sleep over time.
For years, more and more foods were making me feel terrible. Brain fog. Crushing fatigue. The kind of exhaustion that doesn’t go away with sleep. I did what was suggested — I saw doctors, had tests done, followed the advice I was given. That advice was almost always the same: try a low-FODMAP diet. When that didn’t fully work, the fallback was “go talk to a nutritionist.”
So I followed the diet carefully, talked to a nutritionist, and still kept getting worse.
I’m a software engineer, so eventually I did the thing software engineers do: I stopped trusting the general advice and built an instrument to track my own data instead. To be clear — this isn’t medical advice or a diagnostic device. It’s a personal nutrition and symptom tracker, built because the standard guidance wasn’t working for me, and I wanted to see the patterns for myself.
I built a recipe site where I could manage and adjust ingredients to stay FODMAP-compliant. I then added a food sensitivity tracker on top of it to flag potential problem foods based on FODMAP and acid content. It worked exactly as designed. That was the problem — it was designed around FODMAP and acid triggers, so it could only ever tell me about FODMAP and acid triggers. It did what I told it to do, not what I actually needed it to do.
The real fix wasn’t a better model or a smarter prompt. It was admitting that my low-FODMAP hypothesis might be wrong.
I added a much simpler tool to the site: after each meal, log how it made me feel, alongside what else was going on — stress level, sleep quality, the things a lab test can’t see. Not a FODMAP score. Not a verdict from an app. Just my own data, logged consistently over time.
I’d tried keeping a food diary on paper, but it was too hard to draw conclusions from it. I couldn’t keep the meal details, my symptoms, stress, and sleep in my head long enough to compare them, and I wouldn’t reliably remember later which meal had made me feel bad versus fine. I needed something that could keep those variables together and show me the pattern.
That’s what surfaced the real pattern. The exact same FODMAP-compliant meal could make me feel fine one week and awful the next. No amount of medical testing had caught that, because no test was tracking the variables that mattered. The journal did. It pointed toward histamine, not FODMAP — a different mechanism entirely, and not the thing I’d spent months building tooling around.
I’d put a lot of work into the FODMAP and low-acid recipe library, and I didn’t want to throw it out — it might still be useful to someone, and I wasn’t 100% certain of the new hypothesis around histamine intolerance either. So instead of replacing it, I built a second layer: low-histamine variants of the same recipes, a profile setting so the site defaults to whichever approach fits, and grocery lists that generate correctly either way.
With that split in place, the food sensitivity tracker finally had the right question to work from. Instead of flagging things by FODMAP and acid content that weren’t the actual problem, it could point me toward histamine-heavy and fermented foods based on my own tracked history of meals and reactions, not a generic list pulled off a website.
I’m still on this journey — the low-histamine direction is showing real, positive results, but I’m not calling it solved. The newest tool on the site checks restaurant meals against the same sensitivity profile. It works when a restaurant publishes nutrition data, and falls short when it doesn’t — that gap is the next thing to close. (The same tracking philosophy carried over into a second tool I built for skin-reactive products — that one’s its own story.)
None of this started as an engineering exercise. It started because I was sick and the standard advice wasn’t working. But the pattern underneath it is exactly the kind of work I want to keep doing next: take a real, specific, unsolved problem, build an instrument that can tell you something true about it, and let the data — not a generic guideline, not an app’s verdict — guide you toward the real answer, even when it means changing course.
That’s what AI-augmented development means in my hands. Not autocomplete. Not an AI agent handing back a one-off answer on its own. The app didn’t reveal the answer immediately, but it gave me the structure to notice the pattern, iterate on the tool as I learned more, and test a better hypothesis — the pattern behind everything I build.