Most personal tracking projects die within three months. The tooling gets awkward, the habit breaks, the schema starts to fight the reality of life, and the whole thing quietly ends. Felix’s howisfelix.today is notable largely because it has not done that.
The site is a live dashboard of his life, backed by a single database. Sleep, mood, location, habits, work time, food. All of it structured, all of it queryable, all of it visible to anyone who visits the page. It landed on Hacker News with 355 points and 171 comments, which is a reasonable signal that it touched something.
The Hard Part Is Not the Tracking
Setting up a database and writing a few scripts to log events is an afternoon project. Keeping it coherent for years is not. The interesting engineering in something like this is all in the maintenance layer: how do you evolve a schema without orphaning your history? How do you handle weeks where you forgot to log anything? How do you add a new category of data in year three without breaking the visualizations you built in year one?
These are the same questions you face when building any long-running event-driven system. In my own work on bots and automation, the data model that seems obvious at the start almost always gets stressed once real usage runs through it. The difference is that with a personal life database, you cannot migrate away from the legacy data, because the legacy data is your actual history.
Observability for Yourself
There is a framing here that I find useful: this is essentially a personal observability stack. The same principles that apply to production systems apply here. You want low-overhead instrumentation that does not require manual effort every time, a storage layer that you actually own and can query directly, and a dashboard that surfaces the things worth knowing rather than just everything.
Most wearables and wellness apps fail the last two criteria. The data is locked behind an API that may or may not exist in five years, and the dashboards show you what the product team decided mattered, not what you care about. A single database under your own control is a different constraint entirely, and the discipline it imposes tends to produce cleaner thinking about what you are actually trying to measure.
What Consistent Data Collection Looks Like
The gap between starting a tracking system and having two years of reliable data is almost entirely a collection problem, not a storage problem. Getting data in consistently requires:
- Automated sources wherever possible. Manual entry creates gaps; automated sources do not.
- Friction-free manual entry for the rest. If logging your mood requires opening an app, navigating menus, and writing a sentence, you will skip it regularly.
- Tolerance for imperfect data. A system that requires complete records will accumulate anxiety about missed days rather than useful history.
The projects that survive tend to have thought through collection first and schema second. The schema can be fixed later; a gap in data cannot be filled retroactively.
Feliz’s public dashboard adds one more interesting pressure: it creates external accountability. The database does not care if last week was bad; it records it regardless. That kind of honest accounting is harder to maintain with a private journal and somewhat easier when the system enforces it automatically.