Your team needs a custom CLI

Every dev team should build its own CLI. The cost-benefit ratio is so high that I think it's a no-brainer.

Over the last year, our team has spent spare bits of time building and adding to our custom command line utility, ost, and seen big benefits to our workflow both in the obvious time savings, and in other surprising ways.

What we did

All sorts of professions have always built their own tools to smooth their workflows: blacksmiths make fullers, drifts, and hammers; carpenters make their own marking gauges and mallets. All these tools are just right for how they work, and software engineers really shouldn't be any different.

My team's journey started when I got frustrated with a manual process we had to perform a few times a week which involved running a set of SQL queries. This wasn't "hard" work — we just had to open DBeaver and run the query. But that still meant waiting for it to open, manually connecting using the right saved connection, finding the saved query, and then running it. Though the task itself only took about 30 seconds, the rest of the stuff around it meant that overall it took more like 5 minutes.

Since the query itself never changes except for one parameter, this was trivial to automate. I spent half an hour throwing together a script using the click Python library to turn the whole process into a single command: ost advanced-permissions assign <username>. This then got the database connection details from AWS SSM, made the connection, ran the query and printed out a useful message to paste into the chat where the request came in. I even added a random emoji to make it a bit whimsical. Since the CLI app was installed on my path (more on that later), the whole process was reduced to a single command that took about 20 seconds to run end to end.

Over the next few months, we extended this simple script into a fully-fledged CLI tool that we now use every day to check on things across disparate microservices. We've moved from click to Typer to reduce boilerplate and now have a plugin system so that it's easy to add new tools with minimal wiring.

The benefits

There are lots of benefits to having a team CLI, both in productivity gains and some more surprising, less direct positive impacts. I've outlined what I've seen after a year of ost below:

It's always to hand in your terminal

Perhaps the biggest and most obvious benefit is the raw productivity increase we've seen from having just the right tool installed on our system path.

As developers, we almost always have a terminal open on our machines: it's usually the first thing I open at the start of the day and the last thing that I close down. When a request comes in from a user or our product team, we can usually answer it in seconds with a simple command and then get back to what we were doing without interrupting our flow too much.

This has had big benefits for us software engineers, since our context switching costs are now much lower on average, but also for our users, since we can deal with simple queries or requests really easily and get them their answer much more quickly.

It's fun and it's yours

We've had a lot of fun making our team CLI tool: it gives us a lot more creative freedom and discretion around what we build than we do for 'normal' product work. Since we are the users and stakeholders there's no friction to adding features we think are useful, and no hard communication to understand the problem domain better — we're already experts.

This means that working on our dev CLI is really fun, a lot more like the pet projects you might work on in your own time, but with the added benefit of being concretely useful in our day-to-day work. We've also had a lot of fun adding gratuitous 'juice' like full colour ASCII logos and fancy coloured output just because we can.

Releasing a new feature is also a time for some team bonding: we've taken to making over-hyped release announcements in our team chat, complete with GIFs and emojis.

It fosters a 'Continuous Improvement' mindset

I'm a big fan of continuous improvement. One of the most exciting benefits I've seen is that others in the team have caught the 'bug' of continuous improvement because our team CLI has given us the power to effect change. Conversations have moved from "this is a painful process, but I don't know how to make it better" to "let's add that to ost", and there's genuine excitement to do so.

Team members ask about progress of new features that they're looking forward to, and this has also spilled over into more repository-specific tooling too: even if it's not integrated into our team CLI, we're still building more tools to smooth bumps in our workflows and make our lives easier. The team has moved towards automating things much quicker rather than suffering through friction or repeating the same manual process multiple times as part of our 'business as usual'.

It's scriptable and ready for Agentic AI

Linux/Unix tools have taken off because they're composable: you can take a few simple programs, chain them together with pipes, and achieve some very complex workflows.

Since our team CLI is just a CLI, it's easy to integrate into workflows like this: we can write one-off scripts or commands that take our tool, and tack on a jq or grep command to build a quick report or similar.

We've also started writing some agent skills so that as we adopt more Agentic-first software development practices, the agent is able to interact with our systems and check its outputs, building on top of workflows that we already have in place. Over time, this will get more and more powerful, as we can build a 'natural language' interface for our systems to answer support requests. Ultimately this might mean that members of the product team will be empowered to answer more and more questions and perform simple support tasks with the help of an agent instead of always having to find a dev to do it.

Your team needs one too

Hopefully you've seen some of the benefits of having a CLI for your dev team. The barrier to entry is low: all you need is a couple of Python files, and a quick uv tool install to make it available in your path (other languages are available!). Once you've got something working, you'll quickly find that it snowballs into a custom Swiss Army Knife that's just right for your workflow. I've seen other teams adjacent to ours really benefit from starting theirs, and I'm sure you will too.

If you're a team lead — spend an afternoon throwing together an MVP. Make a big fuss about it, and see how your team enjoys making a real difference to their day-to-day workflow: making those 30-second tasks actually take 30 seconds rather than 5 minutes.