Appsmith’s CTO, Arpit, once mentioned in an interview that boring is good. Appsmith is an open source framework that can be used to build internal custom software. Our engineers believe that code should be well-maintained. The steps required to do that (from focusing on code comments to prioritizing readability), however, can be rather dull. But if that what it takes to create well-maintained code, then boring is good.

This is a fitting opinion from someone building a startup that supports engineers creating tools to be used internally by the company. These tools and the process to build them are, of course, notoriously tedious. They are still important, though, and so it would make sense to come to the conclusion again that boring is good. But why exactly are internal tools boring…and what if, unlike code maintenance, they didn’t have to be?

Why internal tools tend to be boring

Creating an engineering tool at least has a few bright points. You can access them via CLIs and get some street cred because other engineers use it. But there’s another class of internal tools – the ones which engineers build for functional users (i.e non-engineers). You know, those workflow UIs or admin panels for support agents, sales folks, marketing and (gulp) HR. Yes, those. Comatose.  

Regardless of how tedious and monotonous these tools are, someone has to build them and there’s a good chance the task will fall to you or a fellow backend engineer. But keep in mind that the reason internal tools are so dull is because they are so terrible to look at and use. Poorly thought-out tools can slow the user down, require them to take unnecessary steps to achieve what they’re trying to do, and overall leave them displeased. So what’s the solution here? Despite your status as a backend developer who likely has little to no training in design, the look and feel of the tools you’re building need to be top-of-mind. 

Here are some things to keep in mind when thinking about building your own non-boring, highly usable internal tools.  

Deciding when to build an internal tool 

There isn’t really a widely accepted, standardized time to build an internal tool. It often starts as a tiny itch (read: pain point), which goes away when you scratch it. But then it keeps coming back until you decide you can’t take it anymore and need a bigger, better, more permanent solution.  

But this ad hoc method is inefficient and slow. It makes more sense to have a pre-set list of criteria that a pain point should meet in order to trigger the team into building an internal tool to solve it. One way to approach this is in terms of how much developer time goes into solving an issue that comes up repeatedly. 

Slack engineers Greg Pelly and Mark Christian share a good rule of thumb: “Consider building tooling around tasks that require a developer to open a browser window.” 

In their post on building internal tools, they share how Slack engineering used this rule to build a variety of CLI tools for their engineering teams to solve problems like syncing files between developer machines and remote servers every time a file is saved, or tools for generating fake data on development servers or fixtures for writing unit tests.

They then created the slack-cli project (now open sourced as magic cli), which is similar to git command line tools, to streamline their workflow by packaging together their individual shell scripts. This shared set of tools helped new engineers focus on their projects, enabled everyone to stay focused on their tasks, reduced the amount of unnecessary information developers had to remember, and allowed improvements made by one person to benefit everyone. 

A similar approach works for tools built for functional teams too, and there’s two metrics that you should consider:

• The time that devs spend serving the operational needs of functional teams

• How many browser windows/clicks/toggles functional teams are currently undergoing to perform their tasks 

If you’re a develo