Dashboards are how software is demoed. The terminal is how a lot of it is actually used. If your buyers are technical, shipping a CLI alongside your web app changes how they adopt you, how deeply they integrate, and — increasingly — whether an AI coding agent can set you up without a human clicking anything.
Here’s the honest case for it, and what it costs.
What a CLI actually buys you
1. Adoption without a demo
A developer evaluating tools wants to try the thing in the next five minutes, not book a call. A CLI collapses evaluation into one command. npx yourtool init is a better first impression than a signup flow with a product tour, for the audience that matters here.
2. Composability
This is the real argument, and it’s the one that dashboards can’t answer. A CLI that reads stdin and writes structured output can be piped into anything — a shell script, a cron job, a CI step, another tool. Every integration you didn’t build becomes possible without you.
A dashboard is a destination. A CLI is a component.
3. Automation and reproducibility
Anything a user does twice, they’ll want to script. Clicking through a dashboard can’t be committed to a repo, reviewed in a pull request, or re-run identically on a new environment. A CLI turns configuration into something that lives in version control — which is how technical teams increasingly expect to manage everything.
4. CI/CD as a distribution surface
Once your tool is invocable from a script, it can run in a pipeline. That’s a category of usage — checks, deploys, syncs, verification steps — that’s simply unavailable to a web-only product.
5. AI agents can use it
The one that’s changed fastest. When a developer asks an agent in Cursor or VS Code to “set up affiliate tracking,” the agent needs something it can invoke and read the result of. A CLI with predictable output and clear error messages is directly usable; a dashboard is not.
This matters more than it looks. If a meaningful share of setup work is now delegated to agents, then being agent-operable is a distribution advantage, not a nice-to-have — the tool the agent can complete the task with is the tool that gets adopted. It’s the same argument as MCP, from a different direction: see building an MCP server AI agents can actually use.
6. It forces a decent API
You can’t build a good CLI on top of a bad API. The discipline of making every operation expressible as a command tends to surface the places where your API assumed a human with a mouse — and fixing those improves the product for every integration path.
What it costs
Being fair about the downsides:
- It’s a second interface to maintain. Every feature now has two surfaces, and they drift if you don’t keep them in sync.
- Distribution and versioning. Packaging for multiple platforms, handling upgrades, supporting old versions people haven’t updated.
- Auth is harder. Browser-based OAuth flows from a terminal, token storage, and credentials that don’t end up committed to a repo by accident.
- Support surface grows. “It works in the dashboard but not the CLI” is a real class of ticket.
- It’s wasted if your buyers aren’t technical. A CLI for a product bought by marketers is an engineering hobby.
That last point is the deciding one. This is a bet on who your buyer is, not a universal best practice.
What makes a CLI good rather than merely present
If you build one, the difference between useful and annoying is mostly conventions:
- Follow the norms.
--helpon everything,--version,--jsonfor machine-readable output, non-zero exit codes on failure, respect forNO_COLORand non-TTY environments. - Structured output as a first-class mode. Human-readable by default,
--jsonwhen piped. Without this, nothing downstream can consume you. - Errors that say what to do next, not just what went wrong. This matters doubly for agents, which act on the error text.
- Idempotent commands where possible, so scripts and pipelines can re-run safely.
- Non-interactive by default in CI. A prompt that blocks a pipeline is a bug.
- Config in a file, secrets in the environment. Committing a config is a feature; committing a token is an incident.
- Fast startup. A CLI that takes three seconds to print help won’t be used in a loop.
Where this fits in the marketing argument
There’s a distribution point hiding in here that’s easy to miss: a CLI makes your product mentionable in a code block. Tutorials, README files, Stack Overflow answers, blog posts, and agent transcripts can all contain a literal command someone copies and runs. That’s a form of word-of-mouth a dashboard can’t participate in, and it’s exactly the kind of third-party content that AI assistants draw on when recommending tools (more on that).
It also lowers the bar for partners and integrators to build on you — which makes technical affiliates and consultants meaningfully more likely to recommend you, because “here’s the one command” is an easier recommendation than “here’s a fifteen-minute dashboard walkthrough.”
Should you build one?
A rough decision rule:
- Your users are developers or technical operators → yes, and probably sooner than you think.
- Your product is configured once and then runs → a CLI plus config-as-code is a strong fit.
- Your product involves data that people will want to move, export, or sync → yes.
- Your buyers are non-technical → almost certainly not. Spend the effort on integrations they can use instead.
And if you do build one, treat the API as the product and the CLI and dashboard as two clients of it. That ordering keeps them honest.
FAQ
Does a SaaS need a CLI?
Only if its users are technical. For developer-facing tools a CLI meaningfully improves adoption, automation, and CI usage; for non-technical buyers it’s effort better spent on integrations.
Why do AI coding agents need a CLI or API?
Agents act by invoking commands and reading results. A CLI with predictable, structured output and clear errors is something an agent can complete a task with; a dashboard requires a human to click through it.
What makes a CLI good?
Standard conventions — --help, --json, meaningful exit codes, non-interactive behaviour in CI — plus errors that explain the next action and idempotent commands that are safe to re-run.
More engineering notes are in the building Qanary hub.