A kanban board is great at one question — what's the status of this card? — and bad at the one a founder actually asks on a Monday: where are we? Are we on track for launch? What's the real blocker? What should I touch first? You can read all the columns and still not have the answer, because the answer is a synthesis, not a column.

So we built a small internal dashboard that does the synthesis. It pulls our live issue board, computes the numbers (launch-gate readiness, distribution by project and priority), and then asks an LLM to write the read: a one-line headline, a launch-readiness verdict with the specific blocking issues, the three things to do next, the risks. Not a kanban — a state-of-play.

The interesting part isn't the dashboard. It's that it adds no production-time LLM cost or dependency at all.

The trick: driven through commits

The obvious way to build this is a web view that, on each page load, calls the issue-tracker API and an LLM, and renders the result. That works, and it's also three things we didn't want in production: an API key for the tracker, a paid LLM call on every render, and a live external dependency that can be slow or down exactly when you load the page.

Instead the dashboard is generated, committed, and served static. A management command does the expensive part locally:

  1. pull the live board,
  2. compute the stats,
  3. ask the LLM for the structured insight,
  4. write the result to a committed board_dashboard.json.

The production app just reads that committed JSON and renders it. No API key on the box, no LLM call at render, nothing to time out. To refresh the dashboard you regenerate locally and commit — push, and prod serves the new read. We call it driven through commits: the artifact is the source of truth, the page is a dumb renderer, and git is the deploy pipeline. The page even shows a "generated 2h ago" stamp so nobody mistakes it for live.

manage.py board_dashboard   # pull board + LLM read → commit the JSON
git commit && push          # prod now serves the new state-of-play

Which LLM, and why it matters for cost

We generate the insight with the subscription-backed CLI we already pay a flat rate for — not a metered, per-token API. For a once-a-day reasoning call over a board, a metered API would be pure avoidable cost; the flat-rate CLI makes it free at the margin. (We keep the metered API for the things only it can do, like image generation and the live customer-facing chat path where latency is critical. Reasoning that isn't latency-critical goes to the flat-rate tool.)

This is a small, repeatable rule worth stealing: reasoning that isn't latency-critical → your flat-rate model; real-time or image work → the metered API. Many "we can't afford to put an LLM in that internal tool" instincts turn out cheaper than they look, once you separate generation-time from render-time and pick the model per job.

What it changed

The dashboard's first read, on real data, said our launch gate was 80% un-started and the marketing site didn't exist yet. That was true, uncomfortable, and exactly the kind of synthesis the columns were hiding. A board makes you read; a state-of-play tells you. Generating it through commits means we got that for the price of a script and a JSON file — and the production app never learned what an LLM is.