Playbook
A Team Dashboard for AI Usage: What Changes When a Tool Gets an Audience
My pod needed visibility only I had: who's on which AI seat tier, what each person's API usage costs, whether our automations were still running. My personal tools couldn't help. "Runs on my laptop with no login" is not a distribution model.
The situation
I've written elsewhere about my personal command center, purpose-built tools that run on my own machine and answer my own questions. But the questions my pod actually had were shared questions. Engineers wanted to know what their own AI usage cost, a number that lived in an admin view only I could reach. The team wanted to check whether an automation had silently stopped without pinging me. Work handed to a background pipeline was invisible until it finished or didn't.
The constraint
Porting my personal dashboard was the obvious move and the wrong one. That thing has no authentication because it never needed any, and bolting an audience onto a tool designed for one person is how you ship something embarrassing. The moment a tool gets an audience, everything you skipped for yourself becomes the actual work: identity, access control, tests on the access rules, docs that don't drift, deploys you can trust.
What I built
A second, separate dashboard: cloud-hosted, Google sign-in at the front door, tabs added one at a time as real needs showed up. Not a product with a roadmap. A shelf.
Version zero shipped with a deliberately silly placeholder widget. That was the point: the deliverable was working sign-in, secrets handled properly, a dedicated runtime identity, and a repeatable deploy, proven end to end before any tab worth having existed. Every tab since has been a routine addition instead of a fresh infrastructure fight.
The tabs that earned their place:
- AI usage across the team. Per-person spend and seat tiers across providers, the governance picture I use for seat decisions.
- "My API Spend." Each signed-in engineer sees their own usage, with estimated (token counts × list prices) and billed numbers in separate labeled sections instead of blended into one confident-looking figure. If I can see what a person's AI usage costs, they should be able to see it themselves. Spend transparency that only flows upward isn't transparency. It's surveillance with better branding.
- Heartbeats. Cross-checks that automations actually ran, alerts when one silently breaks.
- "My Handoffs." Each piece of handed-off work as a card with per-gate status (CI, AI review, human review, merge, deploy, QA), so "where is it?" has an answer that isn't me.
The real judgment went into authorization. A note on scope first: everything here is internal tooling for the pod. None of it describes how our customer-facing product handles auth. Our internal tools share an auth library that comes with a shared roles database, and the obvious move was to use it. I didn't: that database is writable by a different internal admin app, meaning someone else's admin could change who reaches my pod's tabs without me knowing. And the library's bundled default config fails open. So the dashboard borrows authentication (who are you) and owns its authorization: per-tab access config in the cloud secrets manager, deny-by-default, fail-closed. And the deployed app cannot edit its own access list. Its runtime identity is read-only on that config, and the writer is a separate tool that runs locally as me. An internet-facing app that can rewrite its own authorization source is a bad idea wearing a convenience costume.
What the audience taught me
The access rules got their own test suite because written rules rot: the suite fails loudly if any tab lacks an explicit expected-access entry, so coverage is enforced by the build, not my memory.
I trust that suite because the audience found a real gap once. The read/write distinction on one tool's settings was enforced only in the UI. A viewer couldn't see the settings page, but nothing stopped them from calling its write endpoints directly. The gap came to light once accounts other than mine were in the tool, and every write route got its own explicit gate. A personal tool never teaches you that lesson, because the UI and the user are the same person.
Deploy discipline cuts the other way here. In production service repos the standing rule is that a human decides every merge: nothing lands without every required approval and every human comment addressed. On this tool I run the opposite regime on purpose (sole maintainer, internal blast radius, no CI gate) so a change is "done" only when it's pushed, merged, deployed, and the health check passes, in one motion. Same person, opposite rules, both deliberate: the discipline is knowing which risk regime you're standing in.
What I can and can't claim
Adoption now has a first, deliberately basic measure: the dashboard keeps an access log, who signed in and when, so I can see actual visits instead of guessing. That's attendance, not engagement. I still haven't drawn per-tab conclusions from the usage it records, so "the team uses it" sits closer to an impression than a fact. The signals I trust most are still the unsolicited ones: the first non-admin access request came from someone who wanted more access than I'd planned to give (read and write), and the self-serve spend tab exists because an engineer asked for exactly that. Tools people ask to be let into are a different category from tools people are told about.
What I'd do differently
- Treat "runs on my laptop" parts as debt with a date. If I could hand my past self exactly one line from this whole project, it's this one. The handoffs tab reports on a pipeline that still runs locally: if my laptop is off, the view goes stale. The docs rule and the deploy motion are habits, not tooling. Each has held so far, which is what everyone says right up until it doesn't. A team tool with a load-bearing laptop in it isn't finished; it's borrowed against, and the loan should have a due date, not a "someday."
- Gate write endpoints individually from the start. The UI-only enforcement gap was findable by inspection. I found it by audience. Server-side checks per route, day one.
Take what helps
The jump from tools-for-me to tools-for-the-team isn't a bigger version of the same work. It's a different kind of work. The features were the cheap part. AI compressed those. What it didn't compress is judgment about trust boundaries: the deny-by-default config, the test that fails when a tab has no access entry, the decision that the app can't edit its own permissions.
And the tab that matters most long-term is the least technically interesting: the page where an engineer sees their own AI spend, labeled honestly as estimated or billed. If AI usage is going to be visible to leadership (and it is), the cheapest trust you'll ever buy is making it visible to the person first.
Your stack and your team will differ. Take what helps, skip what doesn't.