Case study · private working product
Health OS
I wanted one place for the health routine I actually keep: food, training, and the day in front of me. I built it, I use it every morning, and it is still only mine.
- State
- Private working product
- Who can use it
- Owner only — no public access
- My role
- Product decisions, daily use, review
Every value shown above was invented for this page. These are authored illustrations, not screenshots of the real application, and no personal health data appears anywhere on this site.
Logging was scattered. Acting on it was the harder part.
Nutrition in one app, training in another, bodyweight in a note. Recording things was never the hard part — the distance between recording them and understanding the day was. Health OS is a mobile-first attempt to close that distance: log food, log training, and read the day as one thing instead of three.
It is a tool for one person, by design. That makes it good evidence of how I work and weak evidence of whether anyone else wants it. Both of those are worth saying out loud.
A concept schematic of the loop the tool is meant to close — an illustrative diagram, not an application screenshot. No personal health data appears anywhere on this site.
Decisions & lessons
None of these were features. They were places where the obvious version was wrong and using the thing told me so.
Make food entry faster without making it automatic
From the daily view, the fastest path to logging a meal still routes through the existing food finder and keeps a review step before the final add. The shortcut should remove taps, not remove the judgement about what I am actually recording.
Status: in progress. I am working through this one now — it is a decision in progress, not a released change.Lesson: shorten the path, keep the decision.
A passing build is not device acceptance
A mobile layout change made the five destinations in the main navigation wrap badly on my own phone. The automated browser checks were green. I had to open it, dislike it, and redo the layout before it was usable.
Status: changed and in daily use.Lesson: checks catch breakage; only use catches wrongness.
A summary needs a visible source
A weekly review is only worth reading if I can see what it drew from, so completed training sessions get a source trail back to the entries behind them. Until that existed I had no reason to trust the number at the top.
Status: in use for completed training sessions.Lesson: show the evidence behind a recommendation.
How it actually got built
I defined the problem from my own routine, chose the tradeoffs, and reviewed each change against the morning it had to survive. Rejecting my own work after using it is most of what this project taught me.
AI coding tools did a large share of the implementation and testing. I direct that work, review it, and take responsibility for the result. This is not solo, unaided engineering, and it is not client work.
Useful to me. Demand unproven.
I use the private app every day and keep removing friction I hit myself. That is real, and it is a narrower claim than it sounds: one person using their own tool is not a signal about anyone else.
What I can show
Daily owner use over a sustained period, a working mobile-first nutrition and training log, and the decisions above — each one traceable to something that went wrong in use.
What I haven't shown
That anyone else returns to it, what they would choose it over, or that they would pay. Private use is not outside demand.
What would change that assessment?
A privacy-safe outside test, evidence that someone other than me repeatedly completes a specific workflow, and a clear account of what they chose it over. Shipping a public link would not by itself prove any of that.
What comes next
Keep reducing the friction I hit in my own use, finish the food-entry shortcut properly, and work out whether the integrated daily view matters to anyone besides me. Public access, opening the source, and pricing are questions to test, not release plans — and nothing on this page is an invitation to sign up.