There is a class of software that developers build over and over again, often without realizing it. Hiding in plain sight, this software goes by many names: admin panels, internal tools, line-of-business software, management interfaces, dashboards, and surely dozens more.
These applications empower support teams to suspend user accounts, accountants to approve loan applications, and product managers to toggle feature flags. These apps are custom-built and tailored to the specific needs of a team or business. And when you look closely, you see patterns emerge that make these applications very similar to one another.
At Retool, we think about this class of software a lot. A blanket term for all of it that’s catching on is operations software—custom software that encapsulates the business processes (operations) of teams and individuals. And while it is relatively common, many developers are still missing out on what operations software can do for them and their teams. Read on to learn about the distinct qualities of operations software, examples of its impact, where it sits in your infrastructure, and the struggles faced by those who build it.
Let’s begin by defining “operations software” in one sentence:
Operations software is custom software built to streamline and codify the unique business processes of a team or individual.
There are three critical ideas in this definition.
- Built for unique business processes: this software is designed for a specialized group of users with unique requirements, like internal users at a company. Unlike a SaaS (software-as-a-service) product, which is designed to serve a broad audience, operations software is built to model a workflow that doesn’t exist in exactly the same way across industries or companies.
- Built for productivity:this software is focused on saving time for end users, usually by automating or streamlining a process that would otherwise require significant time to complete manually. The user interfaces tend to be focused on productivity (forms, data tables, charts, and so on), versus differentiated visual presentation (eye-catching animations, scroll effects, or fanciful interaction patterns).
- Built around data:this software enforces rules about how a workflow should be carried out, validating data inputs and outputs, and preventing human errors. It orchestrates multiple data sources, often with privileged access to some or all of them. For that reason, access controls and auditing are usually very important.
You might be as surprised as we were to learn that half of all software built today fits this description. Forrester estimated that $120 billion dollars is spent developing custom software every year, most of which could be described as operations software. As a developer, chances are good that you have worked on operations software before, and will work on it in the future.
Let’s look at some examples of operations software, as well as some custom software that doesn’t fit the definition.
Example 1: LeadGenius Dashboard
LeadGenius built custom software to manage costs for a team of 300+ contractors around the world. Their internal dashboard aggregates data from time sheets submitted by contractors, and allows their internal teams to identify spikes in contractor costs.
This is an example of operations software that is tailored to the unique needs of a company. LeadGenius has a workflow for data analysis that doesn't exist in the same way outside their company. The software they built is for a smaller audience of internal operators, designed to save them hours of manual work every week.
Example 2: Stripe's "Big Red Button"
Stripe built a custom incident response tool they called the "Big Red Button". It provides a simple interface that anyone at Stripe can use to report an outage or service interruption. It creates Slack channels, integrates with external tools like PagerDuty and JIRA, and streamlines Stripe's response to incidents.
This is an example of operations software that was built around a company's unique needs and preferences for incident response. How they name their Slack channels and where and when they push data into other systems is a process wholly unique to Stripe. They built software to manage this process, saving them time and making their incident response scalable and repeatable.
However, not all custom software is operations software.
Non-example 1: Shein's e-commerce site
Shein's public-facing e-commerce application makes it easy for users to browse and buy clothing and fashion accessories. Individual pages are optimized to load quickly and drive conversions. Their site is designed to have a distinct visual style that stands out from competitors.
This is not an example of operations software, as the website is designed to serve a diverse audience of users outside the company. It contains eye-catching visual designs that entice a user to take certain actions. While the website probably contains sensitive personal data for end users (like payment information), its users don’t have privileged access to data about anyone else.
Non-example 2: Salesforce
A SaaS product that needs no introduction, Salesforce provides a customer relationship management (CRM) application that sales teams around the world use to track their contacts and deals. It contains common data primitives for this type of work, like Contacts, Opportunities, and Campaigns.
This example is a little trickier, since CRM is a key part of sales operations, and it does often deal with sensitive user data. But the core SaaS CRM product does not fit the definition of operations software, largely because it does not (by default) conform to the specific business processes of its users. The proliferation of custom tools that sit on top of Salesforce is proof that an operations software layer is still required. That being said, Salesforce is both a SaaS product and a development platform, the latter of which can certainly be used to create operations software.
Operations software usually exists in a supporting role within an organization, living alongside software that serves an external audience. Let’s describe and visualize where operations software might live inside your infrastructure.
Public-facing web apps today are typically deployed to cloud infrastructure, and take advantage of components like application servers, databases, caches, or message queues capable of elastic scale. These infrastructure services are often located in a virtual private cloud (VPC) or other secure network, making most components inaccessible from the public Internet. It is also common to use API-based infrastructure services outside your private cloud to outsource common functionality, like payments, communications (SMS, phone, email, etc), or monitoring.
Operations software is often created using a similar approach. It is deployed inside your VPC, or in such a way where it can access the same data sources and API resources available to your public-facing application. But it differs from your public-facing app in a few key ways.
- It is usually protected by SSO services managed by your organization, and sometimes only available on a virtual private network (VPN).
- It is likely to have privileged access to data sources, so that internal users can take administrative action that wouldn’t be allowed outside your organization
- In general, these applications handle much lower levels of HTTP request traffic, as they are restricted to a limited audience. Instead, these apps are more likely to execute computationally expensive tasks, like export-transform-load (ETL) jobs or longer-running reports on large data sets.
The diagram below shows a high-level overview of this infrastructure arrangement, and where operations software typically sits.
Why do companies of all sizes invest in operations software? Because it saves time for users, and allows them to focus their attention and energy on the work that matters most. Brex created operations software to enable internal teams to edit notification templates, replacing a manual workflow that cost engineers valuable time. DoorDash builds operations software to manage last-mile logistics and create a better rewards program for their Dashers. CommonBond builds operations software to make it easier for their team to manage loan applications.
The resulting efficiencies in these businesses also yield massive financial returns, allowing them to accomplish more with the people and time they have.
Despite the well-documented benefits realized by companies that invest in operations software, it can be hard to prioritize building it. The biggest blocker is the cost associated with building custom software using traditional methods. By “traditional methods”, we mean a process by which a software engineering team builds UI and business logic from scratch, using a diverse array of tools and frameworks, and then deploys an application to infrastructure that requires automation and monitoring.
The innate complexity of traditional software development combines with other factors to become an expensive proposition.
- Software developers are difficult to hire, and their time is both expensive and scarce
- Building web or mobile applications from scratch (or iterating on existing applications) plays out over multiple engineering sprints/iterations, spanning weeks or months depending on project scope
- Deploying, maintaining, and updating applications and infrastructure in production is a significant burden
Because creating software this way is expensive, many developers feel they have to decide between investing in public-facing applications (which generate revenue) and operations software (which improves productivity, creating cost savings). When the two are in conflict, public-facing apps tend to grab the lion's share of developer attention. Developing for thousands (or millions) of external users over a handful of internal users tends to be an easier decision to defend.
Even organizations that have engineering teams dedicated to building and supporting operations software can only move so fast. Instead of building one app for a single customer group, internal software teams need to build many apps for very different customer groups. The marketing ops team has different needs than the support team, who both have very different needs than the accounting team, and so on. Internal ops teams end up once again competing for limited developer time and resources.
The historically challenging economics of building operations software leads to underinvestment in software-supported operational excellence. Internal teams without the capacity to create software usually self-serve with off-the-shelf SaaS products that do ~70% of what they need, but fall back to spreadsheets, one-off admin scripts, or manual workflows to power the rest of their business processes. Unfortunately, these solutions tend to be inefficient, and sometimes leave sensitive data on personal computers where it is vulnerable to theft or exfiltration via malware.
Given the constraints above, developers need to change the economics of software development to start building more of the operations software they need. This requires either increasing the number of people who can build software, or making existing software developers drastically more efficient.
One attractive solution to finding more builders is to empower knowledge workers to create solutions to their own problems. This approach has some major benefits—there are less than 30 million software developers in the world, but hundreds of millions of knowledge workers. Knowledge workers can use “no code” tools like Airtable or Zapier to model business processes with a degree of flexibility. This approach is great and works for many use cases. But often, requirements emerge that call for intervention from a developer, like accessing a production datastore, configuring an API client, processing large quantities of data, or building a complex user interface. For non-trivial use cases, knowledge workers will eventually hit a ceiling on what they can build, and developers will have to either throw away their work, or fight through no code abstraction layers to finish the project.
The other option is enabling software developers to create more software. But if developers could be creating more software, wouldn’t they be doing it already? The solution here comes from developers embracing new technologies that change how they approach software development. Some tools, from GitHub Copilot to DALL-E, use artificial intelligence to make the process of traditional software development faster. Other tools provide domain-specific building blocks and abstractions that give developers more leverage to build software. For operations software specifically, Retool reduces the time and effort required to develop this software by orders of magnitude.
Building software to power your unique business operations has transformative potential. Investing in your people, by building software designed to work the way they work, will pay off through their happiness and productivity. Software is already eating the world–what might be possible if you let software snack on all the "small" problems in your world as well? I'd encourage you to find out.
What kinds of operations software have you built in the past? Have you ever not created operations software, because you couldn’t afford to build or support it in production? What techniques have you used to attack this problem? We’d love to hear from you on Twitter, or you can reach out to me directly at kevin.whinnery@retool.com.
