Private working product / public access on hold
Health OS
I wanted one place for the health routines I actually do: food, training, and checking what matters today. I built a mobile-first tool and now use it daily. It's useful to me; that isn't the same as being ready for other people.
Logging was scattered. Acting on it was harder.
I wanted nutrition, workouts, body metrics, and a daily view to live in one place rather than checking separate tools. The aim was not to invent another calorie counter; it was to reduce the distance between recording something and understanding the day.
A private daily-use system.
Health OS has a mobile-first Today view, nutrition logging, workout logging, trends, and reviewed coaching-related flows. It runs as an authenticated personal app. This is a description of my own tool, not an invitation to register or a claim about health outcomes.
or training→Review
the day→Choose
what's next
Concept diagram, not an application screenshot. No private health data is shown.
Directing a product isn't the same as hand-writing every line.
I defined the personal problem, used the product, made product decisions, and reviewed changes against my actual daily workflow. AI coding tools helped implement and test parts of it. I don't claim that as solo, unaided engineering—or as client work.
There is still work between a successful private tool and a dependable product for others: clearer positioning, safe separation of accounts and data, release testing, support, and feedback from real users.
Small fixes taught me more than new features.
A shortcut from the daily view opens the existing food finder and keeps a review step before the final Add. The faster path did not have to mean automatic logging.
Lesson: reduce the path without hiding the decision.A mobile layout change made the five destinations wrap awkwardly on my phone. Browser checks helped, but I still had to reject it in real use and refine it.
Lesson: a passing build is not device acceptance.A useful summary needs a way to inspect what it drew from. I added a source trail for completed training sessions before treating that part of the review as trustworthy.
Lesson: show the evidence behind a recommendation.These are product decisions from my private use, not independent user research or a public release history.
Useful to me. Demand unproven.
Observed
I use the private app daily and keep improving friction I encounter.
Not established
Whether other people return to it, what differentiates it for them, or whether they would pay.
What would change that assessment?
A privacy-safe outside test, evidence that someone else repeatedly uses a specific workflow, and a clearer account of what they choose this over. A public link alone would not prove it.
What comes next
Keep improving the private experience; investigate whether the integrated daily workflow matters to anyone else. Public access, open source, and pricing are decisions to test—not release claims.
See all projects