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
thePlan started with a practical question: what can realistically fit into my day? I’m building a local-first planning system that brings tasks, priorities, and calendar constraints together. Using it myself exposes the gaps and keeps shaping the work, from everyday usability to the reliability of scheduling decisions.
- My role
- Product owner and technical delivery lead
- Status
- In personal use and active development. Scheduling reliability and recovery are undergoing further repair and validation; those changes remain subject to review and release holds.
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
Scheduling must account for Google and Microsoft calendar events, pinned work, deadlines, and preferred working times. Repair and validation work focuses on making those constraints dependable, including when calendar data is unavailable or circumstances change.
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
Calendar views and scheduling settings
These screens from a fictional demo account show the calendar view and scheduling settings. They illustrate the interface; scheduling reliability remains subject to the repair and validation work described above.
My role
Product owner and technical delivery lead
I define the product’s behavior, set priorities, and lead the technical delivery work. That includes working through requirements and edge cases, reading code, reviewing technical approaches, investigating problems, and deciding what evidence we need before a change is ready.
AI collaborators contribute implementation, testing, analysis, and documentation. I establish their responsibilities and review boundaries, stay involved in the technical discussion, and make the product and release decisions. Independent review helps us catch gaps between what we intended, what we built, and what the tests actually demonstrate.
I also use thePlan myself. That gives me a steady source of practical feedback and sometimes a good reason to reconsider an earlier decision. When something does not hold up, I work with the team to understand why and carry the correction through review and validation.
What it demonstrates
What the work demonstrates
- Turning product intent into explicit behavior, including edge cases and recovery expectations.
- Breaking complex changes into bounded increments with acceptance criteria, review, and recorded deferrals.
- Using independent review to challenge implementation and test coverage, then carrying findings through correction and validation.
- Treating authentication, data integrity, backups, and recovery as part of product delivery.
- Using daily experience with the product to identify defects and reconsider priorities.
Technology: React and TypeScript, with FastAPI, PostgreSQL, and Docker Compose.
Explore
Inspect the product and its delivery evidence
The repository includes the application, architecture, decision records, release exits, and operator documentation. The Wave 1.5 exit is a historical example of release documentation, not a statement of current scheduling readiness.
Keep reading
More from Trish Putnam.