Building My Own Focus Dashboard

Off-the-shelf project management tools are built for human teams. My team is mostly AI agents. The tools do not fit.

So I built my own. It is a web cockpit for one seat that runs on my local machine and is accessible only over my private tailnet. It never sees the public internet. It is the operational center of my multi-agent system, and it works exactly the way I think.

Why SaaS does not fit an agent-driven workflow

Every project management tool I tried made the same assumption: multiple humans collaborating on shared work, each with their own login, their own notifications, their own view. The UI is optimized for that model. Boards, sprints, assignees, comment threads.

My workflow is entirely different. I coordinate a team of AI agents, not a team of people. There is no team inbox. There is no sprint ceremony. The canonical source of truth is a markdown vault on my hard drive, not a SaaS database I do not control. Adapting to a generic tool would mean constant friction between how the tool thinks and how I actually work.

The custom dashboard eliminates that friction. It surfaces exactly the information I need and hides everything else.

How the architecture works

The core of the system is the markdown vault. Every task, decision, and session manifest lives as a file on disk. The dashboard is a thin React layer over that file system.

A Node server runs locally, walking the vault directory tree and parsing the frontmatter of each markdown file. It fans out to JIRA to fetch ticket details when needed, and it reads the session manifests to see what the agents are currently working on. The client polls this tree every five seconds.

This gives me two complementary views of my work. I can slice the data by repository to see where the active sessions are happening. Or I can slice it by area to see the progress of specific initiatives. Both views run off the exact same underlying tree. There is no sync layer, no API to maintain, no data model to keep in alignment with the vault.

The affordances no SaaS would build

Because the dashboard is custom, I can build features that no off-the-shelf tool would prioritize.

The most useful one is the Claude Code session bridge. I can click a button on the web interface, and it spawns a terminal process on my host machine to resume the agent session directly. No copy-pasting session IDs. No switching windows to find the right terminal. One click from the dashboard to the running agent.

The dashboard also includes a direct viewer into the vault, so I can read raw markdown files without leaving the browser. When an agent produces output, I can review it in the same interface where I track the task. The whole operational loop stays in one place.

Private by design, fast by design

The most important design decision was keeping the dashboard private. It is served locally, with DNS resolving to a non-routable tailnet IP. It is completely isolated from the public internet.

This means I do not have to think about user authentication, multi-tenant data separation, or public security vulnerabilities. I can build fast and break things because the dashboard has exactly one user. The absence of those constraints is not a limitation. It is the whole point.

One thing I had not thought through was the other direction. I asked a cloud AI reviewer to read a document hosted on the dashboard, and I handed it a link on the assumption that a link was all it needed. It tried to fetch the link and got nothing, because the address resolves to a tailnet IP that nothing outside the tailnet can route to. I had not thought about who could reach that link until the reviewer could not. I put the doc on GitHub for it instead. The isolation is still the point, but it also means nothing off the tailnet can read the dashboard, including the cloud tools I ask for a second opinion.

This isolation also enforces the cockpit triad principle. The dashboard is my private deep-drill environment. It is dense and unpolished, optimized entirely for operational speed. If I want to share something publicly, I push it to dxdev.com or the notes app. The dashboard itself never crosses that boundary.

Building your own tools is often dismissed as a distraction from real product work. But when your workflow is genuinely unique, the friction of adapting to a generic tool is a constant tax on your attention. I spent a few days building the dashboard. I have saved that time back many times over by not fighting a tool that was built for someone else.

I spent a few days building this, and the five-second poll over a plain folder of markdown files is why it never needed more. There is no sync layer to drift and no second copy of the data to reconcile, so every button on the page reads the same vault the agents write to. The one place that design showed its edge was the tailnet address, which no cloud reviewer could reach, and the fix was a single file moved to GitHub, not a change to the dashboard. That is the trade I would make again: a cockpit that only I can see, running off the vault directly.

dxdev LESSON · paste into your AI coding agent
LESSON: A generic SaaS tool built for team collaboration will fight a genuinely agent-driven workflow run from one desk
SOURCE: dxdev.com/blog/2026-05-10_focus-dashboard
WHAT HAPPENED: Off-the-shelf project management tools all assumed multiple human collaborators, logins, notifications, sprint ceremonies, when the actual workflow was one person at a desk coordinating AI agents against a markdown vault as the canonical source of truth. A custom, private, tailnet-only dashboard was built as a thin layer directly over the vault's file tree, with no sync layer or separate data model to maintain, including a one-click session-resume bridge no generic tool would prioritize. One gap surfaced later: a cloud AI reviewer given a link to the dashboard couldn't fetch it, because the link resolved to a tailnet-only address unreachable from outside the private network.
THE RULE: When a workflow's actual shape, one person at a desk, AI agents, a file-based source of truth, genuinely differs from what generic tools assume, a small custom tool reading the real source of truth directly can eliminate ongoing friction. But keeping a tool private by design also means deliberately checking what external tools or reviewers actually need to reach it.
CHECK MY CODE, then report PASS or FAIL with file:line for each:
  1. Any adoption of a generic SaaS or collaboration tool for a workflow that is actually agent-driven with one person at the desk, without evaluating whether a thin custom layer over the existing source of truth would remove more friction than it costs to build.
  2. Any custom tool or dashboard built with a duplicate data model or sync layer instead of reading the canonical source of truth directly.
  3. Any link or reference shared with an external reviewer or tool, including another AI, pointing to a private-network-only address, without checking that the recipient can actually resolve it.
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.