System: A Local-First Personal Analytics Platform.
A private Android/Desktop product built around a harder question than “how do I log data?”: how should identity, history, offline changes, synchronization, analytics, and user intent behave when the system evolves over time?
The product question
I wanted a personal-data system that could begin with training and later expand into other domains without making every new module a separate app. That meant the hard problem was not simply “log a workout.” The product needed reusable data semantics, offline behavior, scheduling, history, analytics, and conflict rules that could survive over time.
My ownership
I define the product requirements, UI/design flows, analytics rules, offline/sync semantics, scope decisions, and acceptance criteria. I can read and modify the Kotlin and SQL directly. AI is used heavily to accelerate implementation, debugging, audits, and test expansion.
Local-first data without rewriting history
I designed behavior around stable record IDs, pending mutations, conflict handling, and separate local/remote/historical representations. A major design principle is that historical truth should not silently rewrite itself because a current object changes.
That led to regression cases around offline edits, timestamps, invalid observations, personal-best history, sync conflicts, and mutation ordering.
Analytics are product semantics, not decoration
The implemented analytics foundation spans multiple object types and treats Trend, History, and Consistency as context-aware behaviors rather than generic charts. I also defined deterministic performance-model rules, completion states, historical personal-best behavior, and time-window semantics.
Scaling the development workflow with a durable AI relay
As the project grew, I found myself spending too much time manually carrying context between AI sessions. I designed a GitHub-backed multi-worker relay with durable worker state, task contracts, dependencies, handoffs, and controller-managed activation.
Failure-aware product design
A recurring design rule is to prefer behavior that stays understandable when information is incomplete or operations happen out of order. That is why the product has explicit pending states, stable IDs, reversible actions, conflict semantics, archived/history boundaries, and regression cases for offline or invalid observations.
Validation loop
I repeatedly run and field-test the app on Android and Desktop. Instead of relying only on compilation, I use explicit compile/runtime verification gates, regression cases, known-failure tracking, and small implementation batches.
That distinction matters because many failures are semantic rather than syntactic. A build can succeed while a quick-complete action resolves the wrong state, an analytics filter changes historical meaning, or an offline mutation survives locally but is lost during synchronization. I treat those as product correctness problems, not merely bugs to patch after launch.
Where the product is going
The long-term direction is to keep the data model modular while tightening the product layer: cleaner cross-domain primitives, more explainable analytics, better performance guarantees, and a stronger separation between historical facts and current definitions.