There is a certain kind of developer who, at some point, looks at the fragmented mess of their personal data and thinks: what if I just put all of it in one place? Felix did exactly that, and the result is howisfelix.today, a public dashboard that surfaces his life as queryable data.
The project falls into the quantified self tradition, but with a specificity that separates it from the usual fitness tracker crowd. Rather than syncing a few health metrics into an app someone else built, this is a deliberate architectural choice: one database, a defined schema, and a commitment to feeding it consistently over time.
That last part is the real engineering challenge. The hard problem with personal data tracking is not the storage, the queries, or even the visualization layer. It is the pipeline. Humans are inconsistent. Life interrupts logging. What starts as a disciplined daily habit becomes a patchy record after a few months of travel, illness, or just not caring. Anyone who has tried to maintain a personal database knows the friction: you design a clean schema, enter data for two weeks, then lose the thread entirely.
Flix’s site suggests he has kept the thread. That is worth taking seriously, because consistency over time is what transforms logged data into anything actually useful. A year of mood entries tells you something. Two weeks does not.
The Design Decisions That Matter
When you build something like this, the schema decisions compound quickly. Do you model sleep as a single nightly record or as individual sleep segments? Do you track mood as a numeric scale or as categorical labels? Do you log exercise by session, by set, by rep? Each choice has downstream consequences for the kinds of questions you can ask later.
The public-facing aspect adds an interesting constraint. When your database is visible to strangers, you are implicitly committing to a certain level of data quality. Gaps become visible. Outliers are scrutinized. That external accountability is probably part of what keeps the project alive, though it also means every schema migration is a public event.
Why Single-Database Over Dedicated Apps
The case for consolidating into one database rather than using purpose-built apps for each domain comes down to joins. When your sleep data lives in one app, your exercise data in another, and your mood tracking in a third, cross-domain questions become hard or impossible. You cannot ask whether your sleep quality correlates with your training load because the data never shares a context.
A unified schema makes those queries trivial. You can explore the relationships between any two dimensions of your life, not just the ones the app vendor thought to expose.
The tradeoff is that you own all the ingestion work. Every data source needs a pipeline into your schema. That is significant ongoing maintenance, and it is why most people eventually abandon projects like this.
What Felix has built is less a technical achievement and more a demonstration of sustained commitment. The HackerNews discussion reflects that: people are more interested in how he kept it going than in what stack he used. That is the right question to be asking.