01
Keep the hierarchy useful
Epics, projects, sections, tasks, and nested subtasks preserve context without flattening every kind of work into the same row.
← Back to selected work
Selected work · Delivery case study
thePlan
A local-first planning system that connects deep task hierarchy, real calendar constraints, and deliberate scheduling. Built as a daily driver, not a productivity demo.
The problem
Task lists and calendars were solving different halves of the problem
Most task tools can hold a list. Most calendars can hold an appointment. I needed a system that could preserve the full shape of the work and still answer the daily question: what can realistically fit now?
thePlan grew from that gap: a personal planning system with real hierarchy, calendar-aware scheduling, and enough operator control to adjust when the day refuses to cooperate.
The product rule
A plan that ignores the calendar
isn't much of a plan.
Scheduling has to respect hard events, pinned work, preferred time maps, deadlines, and the operator's right to change course.
The delivery decisions
Build the system in waves, and make every boundary visible
02
Schedule against reality
Google and Microsoft calendar events, pinned blocks, deadlines, and painted time maps constrain the schedule instead of being treated as suggestions.
03
Treat operations as product work
Local-first deployment still needs authentication, persistent storage, backups, remote access, migrations, and recovery instructions.
04
Do not hide unfinished work
Exit records name what shipped, what was deferred, and what remained imperfect. A release boundary is useful only when it tells the truth.
The product in use
Hierarchy, time, and operator judgment in one system
These are real screens from a fictional demo account. Together they show the core workflow: preserve the shape of the work, place it against actual constraints, and keep the scheduling rules visible to the person making the decisions.
My role
Product owner, daily user, and acceptance gate
I defined the product rules, divided delivery into release waves, made scope calls, tested the system through daily use, triaged defects, and decided what counted as shipped.
AI collaborators did substantial implementation, test expansion, analysis, and documentation work under my review. The arrangement increased delivery speed without moving product authority or acceptance responsibility out of human hands.
What it demonstrates
Sustained delivery, not a weekend prototype
- React and TypeScript client with a FastAPI, PostgreSQL, and Docker Compose stack
- Wave-based delivery with explicit exit criteria, ADRs, deferrals, and known gaps
- Calendar integrations, constraint-aware scheduling, recurrence, reminders, and mobile use
- Local-first operations with authentication, backups, migrations, and remote access
- More than 250 backend test functions across product, scheduling, auth, and integration behavior
- A defect backlog shaped by actual use, including fixes for fairness, capacity, hierarchy, and recovery
Explore
Inspect the product and its delivery evidence
the repository includes the working application, architecture, decision records, release exits, operator documentation, and the gaps that remained visible after ship.