We Built a CLI for Our Web Analytics Tool
Here is Why a Terminal Dashboard Makes Sense for a Web Product
My co-founder and I build a web analytics SaaS, and we just shipped something that sounds backwards: a command line client. A terminal dashboard for a web tool.
Here is the reasoning, because the decision taught us something about who our users actually are.
The Insight That Started It
A chunk of our users are developers, and developers do not want to open a browser tab to check if their last deploy broke something or if traffic is flowing. They want it where they already are. In the terminal, next to their code and their logs.
What It Does
Live visitor count, an events stream, an errors stream, and an ad hoc query mode. The mental model is tailing logs, but for your site's analytics.
The commands:
watch— live visitor and session viewevents tail— stream events as they happenerrors tail— stream client errorsquery— ad hoc questions
Why This Was Worth Building as a Two Person Team
Every context switch to a browser is friction, and friction is where you lose people. events tail feels like tail -f, which developers already understand without a tutorial. And a developer who installs your CLI has a much higher commitment than one who bookmarks a dashboard. The terminal earns a place in their workflow in a way a browser tab never does.
The Honest Part
The terminal is a hostile place for charts. We keep visuals to sparklines and simple bars, because anything more complex in ASCII is worse than just showing the number. We spent more time deciding what not to render than building the rendering.
The Broader Point
The right interface depends on who your user is, not on what is conventional for your category. A web product does not have to live only on the web.
For those who have shipped developer tools: did a CLI change your activation or retention versus a web-only product? That is the number I am watching now.
Building Zenovay — try the CLI with npx [@zenovay](/zenovay)/cli
This maps well to AI/API tooling too. In Tokens Forge, the dashboard is useful, but the moments developers really care about often happen next to logs: which model route was picked, whether a fallback happened, which balance bucket paid, and how much a run just cost. A CLI for an AI token gateway would probably be less about pretty charts and more about tailing usage events, failed requests, route changes, and budget warnings in the same place people debug deploys. The key is choosing the few facts worth streaming instead of trying to recreate the whole dashboard in terminal.