Best Tech Stack for Building a CLI Tool as a Solo Developer

CLI tools are the most underrated product category for solo developers. No frontend to design. No CSS to debug. No mobile responsiveness to worry about. Just your logic, the terminal, and users who appreciate well-crafted command-line tools. I've built several CLI tools over the years, and the best part is that they're usually feature-complete in a few weeks.

The stack decision for a CLI tool comes down to one fundamental question: do you need your tool to be distributed as a single binary, or is requiring a runtime (Node.js, Python) acceptable? That question determines everything else. Here's what I'd choose.

The Recommended Stack

Why This Stack Works for Solo Developers

CLI tools have a unique advantage: the "UI" is text. You don't need a design system, responsive breakpoints, or browser compatibility testing. This means you can focus entirely on the logic and user experience of the commands themselves.

For solo developers, the choice between Go and TypeScript usually comes down to your audience. If your users are developers who install tools via Homebrew or download binaries, Go is the better choice. Single binary, no runtime dependency, cross-compiles to every major platform from a single machine. If your users are JavaScript/Node.js developers who install via npm, TypeScript is the obvious pick.

I built my first CLI tool in Python, and distribution was a nightmare. Telling users to install Python 3.9+, create a virtual environment, and pip install my package was a non-starter for most people. When I rewrote it in Go, adoption tripled because the install was just "download this one file." The lesson: distribution friction kills CLI tools faster than missing features.

Go Path: For Binary Distribution

Go is the language most CLI tools are written in today, and for good reason. The standard library handles file I/O, HTTP requests, JSON parsing, and concurrency without any external dependencies. Your tool compiles to a single binary that runs on macOS, Linux, and Windows.

Cobra is the CLI framework. Kubectl, Hugo, GitHub CLI, and Docker CLI all use it. The pattern is simple: define commands, add flags, write the logic. Cobra handles help text generation, flag parsing, autocompletion scripts, and subcommand nesting. It's mature enough that you won't hit edge cases that aren't already solved.

Viper (made by the same author as Cobra) handles configuration. It reads from config files, environment variables, and command flags with a clear precedence order. Users can set defaults in a ~/.myconfig.yaml file, override with environment variables, and further override with command flags. This flexibility is expected in modern CLI tools.

Lipgloss and Bubbletea from Charm are the visual layer. Lipgloss gives you styled text output (colors, borders, padding) and Bubbletea lets you build interactive terminal UIs (spinners, progress bars, selection menus). The Charm ecosystem has made Go CLI tools look genuinely beautiful. When I first saw the output from tools using these libraries, I was surprised it was a terminal application.

For distribution, goreleaser automates everything. Push a git tag, and goreleaser builds binaries for all platforms, creates a GitHub release with checksums, updates your Homebrew tap, and publishes to Snapcraft. The initial configuration takes 30 minutes, and after that, releasing is just tagging and pushing.

TypeScript Path: For npm Distribution

If your audience is the JavaScript ecosystem, build your CLI in TypeScript and distribute via npm. Users run npx your-tool or npm install -g your-tool and they're ready to go.

Commander.js is the npm equivalent of Cobra. It handles argument parsing, subcommands, help generation, and option handling. The API is clean and TypeScript-friendly.

Chalk for colored output, Ora for spinners, and Inquirer for interactive prompts give you a polished terminal experience. Inquirer's prompts (checkboxes, selections, confirmations) are especially useful for CLI tools that need user input during setup or configuration.

For bundling, use tsup (built on esbuild). It compiles your TypeScript to a single JavaScript file that starts fast. By default, Node.js CLI tools that import dozens of modules have a noticeable startup delay. Bundling into a single file eliminates that.

One thing I learned the hard way. Add a shebang line (#!/usr/bin/env node) to your entry file and set "bin" in your package.json. Without these, npx won't know how to run your tool. It's a two-minute thing that's easy to forget and confusing to debug.

Testing CLI Tools

CLI testing is different from web testing because you're testing input/output at the process level. For Go, the built-in testing package works well. Run the command as a subprocess, capture stdout and stderr, assert on the output.

For TypeScript, use Vitest and test your command handler functions directly. For integration tests, spawn your CLI as a real command using Node's child process utilities. Both approaches catch different types of bugs, and I'd recommend having both.

The most important thing to test in a CLI tool is error handling. What happens when the user passes an invalid flag? What happens when a required file doesn't exist? What happens when the network is down? CLI users expect helpful error messages, not stack traces. Test every error path you can think of.

What I'd Skip

Rust for your first CLI tool. Rust produces great binaries, but the learning curve is steep. If you already know Rust, use it. If you don't, Go gives you 90% of the benefits with a much shorter time to productivity. You can always rewrite in Rust later if performance is a bottleneck.

Electron-based CLI wrappers. I've seen people package Node.js CLI tools with pkg or similar tools that bundle the Node runtime. The resulting binary is 50-80MB for a tool that does text processing. If you need binaries, use Go. If npm distribution is fine, stay in Node.js.

Interactive TUIs for v1. A full terminal UI (like a dashboard that takes over the whole terminal) is cool but complex. Start with simple command-output interactions. Add interactive features in v2 when you know what users actually need.

Monorepo structure. A CLI tool is usually one package. Don't set up a monorepo with workspaces for a single program. One src/ directory, one package.json, one build command. Keep it flat until you have a reason not to.

Getting Started

Here's what I'd do this weekend.

1. Pick your path. Binary distribution? Go. npm distribution? TypeScript. Don't agonize over this. Both work great.

2. Scaffold the project. For Go: go mod init github.com/you/tool and install Cobra. For TypeScript: npm init -y, install commander, chalk, and tsup.

3. Build one command. The main command that does the core thing your tool does. Get it working end to end. Don't add subcommands or flags yet.

4. Add error handling. Make every failure produce a clear, helpful error message. This is what separates amateur CLI tools from professional ones.

5. Publish. For Go: set up goreleaser and push a v0.1.0 tag. For TypeScript: run npm publish. Get it in people's hands and iterate from there.

CLI tools are the fastest path from idea to shipped product I know of. No UI framework debates, no design reviews, no responsive testing. Just clean code that does useful things. And developers love good CLI tools. Build one that saves someone 10 minutes a day and they'll tell every developer they know.