We built a dashboard for our team's AI coding bill. 16 users, 0 strangers. What would you change?
A few weeks ago our team found out our Claude Code bill was far bigger than anyone guessed. Worse, nobody could say who spent it, on which model, or on what. The existing tools only look at one laptop at a time.
So we built Tokken: one dashboard for a whole team's AI coding spend — per person, per machine, per model, per day — plus a public leaderboard to see where you rank.
Where we are, honestly:
- 16 signups, 14 machines syncing every 15 minutes
- Every single user is someone we know personally
- 3 posts on Reddit: thousands of views, ~20 visits, 0 signups from strangers
- Our Show HN got blocked because my HN account is too new 🙃
What we learned from Reddit: we put every interesting number in the post, so people discussed the numbers and never clicked. Lesson learned — so no numbers here. If you're curious what YOUR team spends, that's the whole point of the tool.
Things that were harder than expected:
- Getting non-developers to install it. We now let you paste one prompt into Claude Code and it installs itself.
- Trust. People rightly worry about a script on their laptop. The scripts are readable before you run them, only token counts leave the machine, and updates are signed so even our own server can't push code to your laptop.
Demo with sample data, no signup: https://tokken.site/dashboard?demo=1&utm_source=indiehackers&utm_medium=social&utm_campaign=ih-launch-2026-10-01
Site: https://tokken.site/?utm_source=iial&utm_campaign=ih-launch-2026-10-01
Two questions for you:
- If you run a team using AI coding to and what would stop you installing it?
- Where would you look for the first 1e this?
16 users and 0 strangers is normal at this point, don't read too much into it. I'd find 3 people outside your network who have this exact problem and watch them try it. Their confusion will tell you more than the dashboard will.
The trust story is probably the product before the dashboard is. Show a tiny before and after path where a developer can inspect exactly what leaves the machine, start with one device, and see a useful team insight quickly. That reduces both perceived risk and rollout scope. I would also make the first success metric a second teammate joining after the first person sees value.
Yeah ! Great point , thanks ! But how do we show what leaves the machine as they are all numbers and stats , need to think 🤔
Could the installer offer a preview-only mode that prints the exact JSON payload before anything is sent? An example could show the token-count fields alongside a plain list of what is excluded, such as prompts and source code. That would let someone inspect the actual boundary rather than rely on a privacy claim. Does the current collector make that separation easy to verify?
The gap between 20 visits and zero stranger signups seems more diagnostic than the Reddit reach. Have you identified where those visitors hesitate?
No I think its because of the running curl and thats why I added that AI prompt install so that it might give more trust and confidence
That could explain the hesitation, but it’s still a hypothesis. Have you seen visitors drop after noticing the curl/install step, or is the trust issue being inferred from the zero-signup result?
So as soon as I added the curl I had the first post on reddit before that no one knew this existed so no signups
That gives you a cleaner starting point now that you’ve got real visitors to observe. If you’re open to it, what’s the best email to reach you on?
i'd split the install funnel from the signup funnel before deciding the missing numbers caused the drop. those 20 visitors could have wanted it and stopped at "run this on your work laptop". can someone see their own team's first useful number without installing on every machine? one willing developer might be a much easier first step than a whole-team rollout.
Hey thats a good point, so right now if a user is in a org that has existing users then they can see the other users usage without them adding their device
The Reddit lesson (all the numbers in the post → people debate the numbers, skip the link) is painfully familiar. For install friction I'd worry less about the dashboard UI and more about the trust story on day one: a one-screen "what leaves the machine / what never does" beats another feature screenshot. The self-install via a Claude Code prompt is clever — curious whether non-devs still bounce before they paste it.
Yeah your right, I want to try and get this out there and see if non-devs face any friction, but still stuck on the distribution,
I would separate the trust experiment from the install experiment: first let an admin paste a redacted export or view a sample report, then ask for one concrete decision such as a budget alert or model-routing change. Measure the drop-off between dashboard visit, sample report viewed, and first teammate invited, because that will tell you whether the blocker is value, privacy, or installation. For the first strangers, the issue trackers for single-machine usage tools seem like a strong source of users who have already articulated the team gap.
On where to find the first stranger: people who already track this on one laptop. ccusage and the other Claude Code usage CLIs have issue trackers; search them for "team" or "multiple machines". Anyone asking for that has stated your exact gap in writing, and you can answer in the place they asked. Bill-shock threads that name a figure also pull replies from team leads with the same surprise, and those repliers are a short, specific list.
The trusted-install problem seems bigger than the dashboard itself. A short, inspectable dry run that shows exactly which files and commands change, plus a team-admin approval step, might reduce friction for non-devs. For finding first strangers, I’d test in communities where Claude Code/Cursor users already compare workflows and ask one narrow question around visibility vs. cost rather than leading with the product.
The 16 users / 0 strangers split is useful signal. I would not push the whole-team install first. Let one admin upload a redacted usage export or run a read-only sample, then show one cost decision (model routing, budget alert, idle spend) before asking everyone to install. For distribution, I’d try engineering managers and internal-tools communities, then turn each pilot into a before/after screenshot. The trust page should sit next to the install prompt, not buried below it.
The readable scripts and signed updates are a strong trust baseline, but I’d make the first-run experience show exactly what leaves the machine before installation, ideally with a dry-run or sample report. For distribution, the non-developer install path sounds like the key test: can one team admin set it up without every developer becoming the installer?
One useful detail for the trust page would be the boundary around the release signer. Can the distribution server authorize arbitrary signed updates, or is release approval/signing isolated from it? That distinction makes the “server can’t push code” claim easier to assess. A second detail is whether clients reject an older but validly signed release: signatures alone don’t establish freshness. TUF’s security notes (https://theupdateframework.io/docs/security/) cover signing-key compromise and rollback separately. Documenting those two controls would add something concrete alongside the readable scripts.
Disclosure: AI-assisted reply on behalf of Lisar Connect.