Why is it so hard to build internal CLI tools?

Hey! We're Fig. We make the shell easier and more collaborative. Today, we are talking about internal CLI tools, the problems engineers face when building them, and why we're building Fig Scripts. We're hoping Fig Scripts will become the fastest way to build and share internal CLIs. We'd love to hear your feedback!

Internal CLI tools help engineering teams move faster. Companies like Stripe, Airbnb, and Shopify use internal CLIs to automate workflows, onboard new hires, enforce policies, and standardize on best practices. And what better place to build a developer tool than the shell: every one uses the shell, it's super close to where you're already working, and just about every other tool integrates with it.

But, given how great internal CLI tools seem, why doesn't every engineering team have one? We think it's because building internal CLIs is harder than it should be. And we're building Fig Scripts to change that.

What goes into building a CLI tool?

You'd think most of your time building a CLI would be spent writing business logic. Just write your script and you are good to go! Unfortunately, the logic is only the tip of the iceberg. A lot of the work building/maintaining internal CLI tools involves handling boilerplate.

Some common problems you'll run into: how do I

• distribute the CLI to my teammates?
• make sure my teammates are on the CLI's most up to date version?
• accept user input?
• validate user input?
• track usage analytics and errors?
• add coloured output? (crazy, I know)

It's effectively the age old problem of taking something that "works on my machine" and turning into a production app.

What happens when teams want to build CLIs?

All of the above issues are solvable, but there's a tradeoff. How much time are you willing to put in to build/maintain the CLI vs how much time does it save you and your team?

Here are the typical ways we see teams respond to this dilemma:

1. They don't create a CLI tool. It's too much work. Instead, you write a readme or a Notion doc. Or maybe you don't even do that. Maybe, you just share things through slack, word of mouth, and tribal knowledge.
   
   
2. They do create a CLI tool, no one “owns” it, and it falls apart. You're excited. You build the tool and release it, but you underestimate how much maintenance work is involved. It's not your job to fix it. You find that there is just enough friction to maintaining the tool that bugs don't get fixed and features don't get added. People end up resorting back to their own personal workflows. Now you're back to where you started.
   
   
3. They do create a CLI tool, but a whole team is paid to maintain it. This works but 1. it's expensive and 2. the best engineers on your team are usually the ones who end up owning it. This takes them away from doing other work!

As I'm sure you can tell, none of these outcomes are super optimal.

Fig Scripts

Fig Scripts makes it ridiculously easy to build internal CLI tools and share them with your team. Think "Retool for internal CLI tools".

Here are the 5 key things we are focusing on to make the experience great:

• Create: Write scripts with a Jupyter-notebook style interface, chain multiple languages together, and accept inputs using Fig's out-of-the-box terminal UI library.
• Share: Create/edit a script and it's instantly accessible to everyone on your team. You can even publish scripts publicly
• Execute: Run scripts like normal CLIs. If you don't know what options/arguments to pass, Fig will create terminal UIs with suggestions
• Discover: The Fig dashboard automatically documents your scripts and CLIs. You can also access all your scripts from the shell by running fig run
• Analyze: Fig captures usage analytics and error outputs for every script execution. You'll immediately know who's using the tools and what's breaking.

The Fig Scripts experience is designed to be easy for both creators and users

I'm not going to go in depth on how Fig Scripts works. We have a whole other blog post for that. However, this 30 second demo should give you an idea of how powerful it is

What internal CLI tools have teams created with Fig?

Literally everything... Teams are using Fig Scripts for conventional git commit message templates, onboarding new hires, creating preview environments, switching AWS profiles, pulling secrets, setting up local kubernetes dev environments, setting up Conda environments.

We plan to highlight several teams and individual users in an upcoming blog post.

What's next?

We've just shipped multi-step scripts. This makes the creation interface more like a Jupyter notebook and lets you use multiple languages in the same script. But we still have plenty more to do! Next we're going to add new cell types (like markdown and output components), integrations with popular developer tools (like AWS, Slack, Datadog, Sentry, GitHub, Vault...), cron jobs, and the ability to run scripts in the cloud.

We know many people might read this and think "why can't I just write a bash script and share it in git" - that's okay, you can do that to! Fig Scripts is a different way of creating scripts to automate developer workflows. And if you're skeptical, we highly encourage you to give it a try :)

Either way, please give us feedback (positive and negative!). It's very easy for us to build the features you need - just email me (brendan@fig.io)!

Get Started

• If you use fig, just run fig and click on the Scripts & CLIs tab
• If you don't have Fig, download it from fig.io/download or just brew install fig

Seriously, it will take you 2 minutes to have a script/CLI tool that you can share with your team. I guarantee it 😊

Want to stay up to date? Follow us on Twitter: twitter.com/fig