Why this exists
Digital Braid is a company of one. It still has everything a go-to-market team has: a pipeline of prospects at different stages, active engagements with next actions and due dates, emails waiting on replies, and a growing library of reusable code that is the actual moat. The default answer is to buy a CRM, a project tracker, and a dashboard product, then spend Sunday nights keeping all three in sync with reality.
I run the practice out of a folder instead. Every client and every prospect is a directory with a status.yaml a human can edit in ten seconds, a runbook.md that accumulates everything I learn, and a tasks.md. The files are the CRM. They sit in git, they never disagree with a database, and updating the pipeline is a one-line edit, not a form with eleven required fields.
The dashboard is the part that makes this feel like a system rather than a filing habit. A small local server reads those files — plus every Claude Code transcript on the machine — and renders mission control: what's live right now, what's overdue, who's waiting on me, what each engagement cost in tokens, and what an LLM thinks my runbooks say I should do next. I was my own first client for the exact thing I sell: AI-native operations for a business that lives in files.
Try it — every name is synthetic
This is the real dashboard, frozen. The build pipeline runs the actual server against a fabricated workspace — three invented clients, eight invented prospects, fabricated Claude-session transcripts — and snapshots the API responses into static files. Click the tabs, open the pipeline, hit Scan with LLM on a client card.
Three of the eight tabs are in the demo (Today, Clients, Prospects). The rest are described below. Open it full-screen.
How it works
There is no database and no ingestion pipeline. The server re-reads the YAML and markdown on every request, so editing a file in a text editor isupdating the system. Claude Code writes its transcripts as JSONL on disk as a side effect of me working; a filesystem watcher tails those files and pushes updates over a WebSocket, which is how a session shows up as “live” in the dashboard within seconds of me typing in a terminal.
The session parser turns each transcript into telemetry: which tools ran, what got edited, token counts per model, and — the useful trick — which client the session was about, inferred from the file paths the tools touched. Work on clients/meridian/… and the session, its cost, and its recent activity all attribute to Meridian automatically. Nobody logs time. The telemetry is a byproduct of doing the work.
The three rules under it
If the dashboard died tomorrow, nothing is lost — the YAML and markdown are the system. The dashboard only ever reads; it writes nothing.
Token math, costs, and date bucketing run through plain Python. No model ever generates a number an operator might act on.
LLM output is labeled, cached by content hash, and every extracted action item carries its source line and a confidence level.
The LLM scan is the newest piece and follows rule three: a click sends a client's runbook to Claude and gets back action items and open questions — but every extracted item carries the runbook line number it came from and a confidence level, and results are cached by content hash so re-scanning an unchanged runbook is free. The model proposes; the operator can always check the receipt.
Publishing this without leaking anything
The interesting engineering in the public version is what it took to make it safe. A dashboard whose entire job is surfacing client data is the last thing you casually publish. The demo pipeline builds a synthetic workspace from scratch — invented companies on the reserved .example TLD, fabricated transcripts with plausible token usage, canned LLM-scan results — and runs the real, unmodified server against it. What you click is the actual product reading actual (fake) files.
Then a blocklist gate greps the entire output bundle for real client names, people, and domains, and hard-fails the build — deleting the bundle — on any hit. That gate earned its keep on day one: in one test configuration the server module had already been loaded pointing at my real workspace, the snapshot quietly captured real engagement data, and the gate caught it and killed the build. The fix was one line. The lesson is the reason the gate exists: never trust a sanitization step you haven't watched fail.
What the demo doesn't show
Five tabs are locked in the demo because their data is inherently personal to this machine: Sessions (a year-long heatmap and token analytics across every Claude Code session), Conversations (full-text search over every transcript with a split-pane viewer), Library (each reusable module cross-referenced with which clients import it — the moat, measured), Components (inventory of installed agents, skills, and MCP servers), and Health (environment diagnostics). Same architecture: parse files that already exist, render the truth, write nothing.
Stack
FastAPI + a filesystem watcher on the back, vanilla JS and Chart.js on the front — no build step, one CSS file. PyYAML for the operator files, the Anthropic API for runbook scans, 28 pytest tests around the parsers and the snapshot pipeline. The public demo is the same frontend with a 120-line shim that redirects fetches to frozen JSON and stubs the WebSocket. If you strip the dashboard away, the system still works — it's just folders and YAML. That's the point.