Back to Play
Building Field note

ShadowPM

A lightweight backlog and delivery tracker for solo builders and small projects. Not Jira for one person. More like a quiet layer for keeping work visible, decisions honest and loose ideas from pretending they are progress.

Stream Building
Format Log
Updated 08 July 2026
On this page
  1. Why Jira-for-one fails
  2. What it is
  3. The AI loop
  4. What building it taught me
  5. Status

A lightweight backlog and delivery tracker for solo builders and small projects. Not Jira for one person. More like a quiet layer for keeping work visible, decisions honest, and loose ideas from pretending they're progress.

Why Jira-for-one fails

Heavyweight trackers solve coordination problems: many people, shared state, accountability across teams. A solo builder doesn't have those problems. What a solo builder actually needs is memory (what did I decide, and why) and momentum (what's genuinely next, not what's shiniest). Most tools price those two things behind ceremony designed for thirty people. So I built the version without the ceremony.

What it is

Two small systems that grew together and now work as one:

  • A Django + REST API core with a React board: projects, epics, tasks and sprints, with a five-column execution view and bulk operations for the unglamorous work of keeping a backlog truthful (import/export, bulk re-prioritise, bulk clean-up).
  • A zero-dependency Python layer for fast capture and oversight: a quick-add web UI that runs from a single file, and a master view that aggregates the backlogs of every product I run into one screen.

Local-first on purpose: SQLite and JSON files I own, no vendor, no login wall between me and my own plans.

ShadowPM sprint board with five execution columns
The sprint board: five columns, a sprint-health nudge, and nothing that needs a training course.

The AI loop

The part I use most. Work proposed by my AI tooling arrives on the board through signed webhooks, carrying provenance: which agent produced it, from which run, as what kind of proposal. Nothing executes on arrival; it lands as visible, reviewable intake. An agent-activity dashboard shows what the agents have been up to and what state their work is in. The design rule is boring and strict: AI proposes, I dispose. The board stays honest because nothing gets to skip the queue.

Agent activity dashboard showing agent-generated tasks with provenance
The agent-activity view: every AI-generated task arrives labelled with its agent, run and proposal ID.

A task on the wire looks like this (trimmed):

{
  "title": "Draft outreach note for pilot users",
  "status": "READY",
  "priority": "MEDIUM",
  "source_system": "personal_ai_company",
  "source_agent": "content-producer",
  "source_kind": "proposal",
  "source_run_id": "run_2026_06_18_042"
}

What building it taught me

Any tracker rots unless updating it is cheaper than not updating it. Features didn't fix that; removing steps did. The second lesson: visibility changes decisions on its own. Once every product's backlog sat on one screen, half of my "priorities" quietly resigned.

Master backlog aggregating six products into one view
The master view: six products, one screen, no favourites.

Status

In daily use: this site, and the tool itself, are both run through it. On the bench: an async outbox for agent-side delivery, and better board discoverability. It earns its keep by staying small.