Foreground: the work you keep putting off, surfaced
A single-person prioritization tool that treats the tasks you keep skipping as a signal.
The story in three parts
Important work sinks
Every to-do list has the same failure mode: important work sinks to the bottom and stays there. I wanted a tool that noticed when something had sat untouched and pushed it back up.
A transparent score, run on its own backlog
It ranks everything by a transparent score and manages its own development the way it was built to manage my work. Open source under the MIT license, with tests in CI.
One user, who stopped
Live as a browser demo on seed data. One user so far, me, and I stopped using it: getting my tasks in took more time than I had.
The buried task in 20 seconds
What the work turned up
The fix is setup, not ranking
The top future opportunity is a first-run path to your own list, not a better ranking.
A boundary case corrected the model
The framework's central claim was math-checked and corrected when a boundary case disproved it.
The flow, checked against the code, has gaps
No way to start with your own list, import two hops deep, and nothing that brings a user back.
The problem
Every to-do list has the same failure mode: important work sinks to the bottom and stays there.
The loudest, newest, or easiest items get done first, and the ones that actually matter get postponed until they turn into emergencies. I wanted a tool that noticed when something had sat untouched and pushed it back up, without letting neglect alone manufacture false urgency.
The professional practices it mirrors
Foreground was built to apply the frameworks and rituals of professional product work to my own workload, and shipping it was itself an exercise of those same skills. It is a single-person prioritization tool that treats the tasks you keep skipping as a signal, ranks everything by a transparent score, and manages its own development the way it was built to manage my work. These are the same frameworks I use in professional product work, pointed at my own workload in a tool I specced and shipped. It is not a replacement for enterprise tooling or process, just the same thinking at personal scale.
- A prioritization framework. A WSJF adaptation, cost of delay over job size, applied to real work, with a deliberate addition: a staleness multiplier, because avoided work is the actual failure mode in a personal workflow. The model is written up in FRAMEWORK.md as a standalone artifact with its weights and rationale, and its central claim was math-checked and corrected when a boundary case disproved it.
- Backlog grooming. Raw captures become well-formed user stories with acceptance criteria before they become work.
- Dependency management. Work is modeled as a graph, so blocked items sink and the work that unblocks them is boosted, the same reasoning behind sequencing a real roadmap.
- Explicit tradeoffs over gut feel. Every ranking shows its arithmetic, so a priority is defensible rather than intuitive.
- Roadmap discipline. The app's own development is managed as a groomed backlog inside the app, so the tool prioritizes its own roadmap using the framework it applies to everything else.
The features that make practicing those workflows possible
- What Now. The ranked queue, with a full factor breakdown on every row.
- The Product module. A kanban board of user stories with acceptance criteria and WSJF inputs, where the app's own roadmap lives.
- The grooming assistant. An LLM drafts a user story with proposed acceptance criteria and scores; I accept or edit it, and nothing auto-applies. Drafting is assisted; the judgment stays mine.
- Dependency chains. Waits-on and would-unblock views that follow the chain to its actionable root.
- Stuff I've Put Off. A staleness-ranked view that surfaces avoided work instead of letting it sink.
- Bulk import. Paste a list, one thing per line, review the structured rows, and nothing saves until you confirm.
- A guided tour. First-time demo visitors can walk through the screens before touching the sample data.
Built and verified
Foreground is a React and TypeScript app. The live demo runs on a localStorage adapter, one seeded copy per visitor; a Supabase adapter is built behind the same interface but not yet switched on. A grooming assistant turns raw captures into structured user stories: it calls the Anthropic API when the host has the live model switched on, and otherwise returns a labeled local draft. Claude Code built it autonomously from the spec. CI runs typecheck, lint, and unit and component tests, and a scripted Playwright walk-through drives the main screens. The prioritization model and the judgment behind each weight are written up in FRAMEWORK.md and DECISIONS.md, so the framework can be read and challenged, not just used.
Design process
Foreground has one real user so far: me.
I used it on my own workload for a while, then stopped, because getting my tasks into it took more time than I had. These design artifacts start from that. Anything resting on assumption rather than evidence carries an (A) label, and the labels stay until interviews replace them.
Where it stands
- Live as a browser demo on seed data, and open source under the MIT license.
- Every ranking factor is documented and every framework weight is defended in writing rather than hand-waved.
- Unit and component tests run in CI; a scripted Playwright walk-through covers the main screens.
- One user so far, me, and I stopped using it: getting my tasks in took more time than I had. The top future opportunity is a first-run path to your own list, not a better ranking.
- A morning check-in is a groomed story in the app's own backlog, not a built feature.
Shipping Foreground drew on the same practices it models: a written spec, a defined prioritization framework, a prioritized backlog, a test suite, and a documented decision log.