How /pm-flow became a framework, and grew up alongside a fitness app.

A worked example of building software differently — one PM flow enforced research, planning, testing, and learning until it became a measurable framework.

The story starts here

This started as a personal project.
I wanted a faster, simpler way to track my own fitness and wellbeing — and to keep that data private, on-device, and mine. What grew out of it was bigger than the app.
Building the app kept surfacing the same planning mistakes.
Missed edge cases. Skipped research. Ship-first-measure-later. I was fast and wrong, a lot.
Privacy-first, on-device, owned by the user.
Every byte of health data stays local unless the user explicitly shares it. No cloud AI round-trips. Analysis happens on-device when possible, by design.
9
phases
So I built /pm-workflow — one command, nine phases.
Research → PRD → Tasks → UX → Implement → Test → Review → Merge → Docs. The workflow enforced what I wouldn't.
8
framework versions
Then the workflow itself started evolving.
Each feature ran through it. Each run exposed gaps. The framework grew to close them: caches, evals, dispatch intelligence, measurement.
17
chip profiles
By V7.0 it was measuring itself and routing to hardware-aware models.
Phase timing instrumented. Cache hit rates tracked. Chip-affinity maps for model selection. The tool had learned to profile its own work.
185
audit findings
16 features shipped. All documented. All honest — even the failures.
185 audit findings, 12 critical, published in a public showcase repo. No triumphant narrative without the regressions.
This site is the guided tour. The timeline is below.
↓