Personal Manager
Personal task OS. Eisenhower matrix, day/week timeline blocks, and category lanes (work · mental · physical · social · music · learning).
TL;DR
- Three modes, one data model — categories, priority matrix, and timeline blocks all read the same tasks.
- Built around how a senior IC actually structures a day, not a generic project-management metaphor.
- Vite + React + TypeScript + Tailwind — small, fast, no backend, no lock-in.
- Used daily; the design choices come from friction in my own workflow, not user research personas.
Architecture
One task collection, three ways to see it. No backend — the store is in-memory, persisted to localStorage. Every view reads and writes the same tasks.
Try it
This is the real build. It opens full-screen with a way back to this page, stores everything in your own browser and talks to nothing — close the tab and it is gone.
Problem
Most personal task apps are either rigid (a flat checklist) or feature-soup (a kitchen-sink workspace). Neither matches how I actually run a day: a small set of dailies, a few hours of deep work, and a long tail of categorical commitments (physical, mental, social, music, language) that get visible attention only if the UI surfaces them.
Approach
A tri-mode workspace built around the same task collection. Mode 1 is a categorical lane view (dailies / work / mental / physical / social / music / reading / learning / language) so nothing slips out of awareness. Mode 2 is an Eisenhower matrix for triaging the queue (important/urgent quadrants). Mode 3 is a timeline with explicit planning blocks for scheduling the day. State is local-only for the prototype — no auth, no sync — to test whether the model fits before adding overhead.
Deep dive
One model, three modes
The design bet is that a task doesn't change when you look at it differently — only the framing does. So there is exactly one task collection, and each mode is a pure projection of it: category lanes group by domain, the Eisenhower matrix bins by important-vs-urgent, the timeline places blocks against the clock. Dragging a task in one view mutates the shared model, so it re-sorts in the other two for free. No mode owns the data, which is what keeps the three from drifting out of sync.
Why local-only for the prototype
The open question wasn't 'can I sync tasks' — it was 'does the tri-mode model actually fit how I run a day'. Adding auth, a database and sync before answering that would have been building infrastructure for a hypothesis I hadn't tested. Local-only (in-memory plus localStorage, no accounts, no network) kept the whole thing to a Vite bundle I could iterate on daily, and let the design earn its keep before any backend overhead.
What a v2 adds
The prototype answered its question — the Eisenhower view became the mode I reach for most, and the timeline blocks earn their place during the night-before planning pass. A successor build would add Supabase sync so the same tasks follow me across devices, and a mobile-first capture flow so a task can go in the instant I think of it rather than waiting for me to be at a desk. The data model is already the stable part; those are additive.
Outcome
Working prototype, used personally. The Eisenhower view turned out to be the most-used mode; the timeline blocks help during pre-planning the night before. A successor build would add sync (Supabase) and a mobile-first capture flow. Surfaced here as a finished R&D piece rather than a shipped product.
Related
