Perhaps the single most important question facing modern software engineering teams is: “What should we be working on?” With COVID accelerating the pace of digital transformation and engineering time becoming even more scarce, it’s critical to ensure that your developers are working on what matters most to the business.
In particular, the decision to build internal tools — custom software used solely by employees — can be a tricky one to evaluate. Internal tools may not seem like a priority, especially when weighed up against flashy customer-facing features or product innovations. Yet we’ve all seen that the right internal tools can drive huge efficiency and productivity gains across an entire company. So the question becomes: “How do you evaluate internal tools projects to determine which ones are worth investing in?”
Below, we’ll guide you through a basic framework that can help you answer this question. Of course, every situation is different and these rough formulas can’t capture all the nuances that go into this decision, but it should (hopefully) serve as a helpful guideline in evaluating your own internal tools projects.
Analyzing the true costs of internal tools
The true cost of developing internal tools is the sum of:
- Upfront development costs
- Future operational, maintenance and upgrade costs
- Opportunity costs
A common mistake when evaluating internal tools projects is to focus too much on the upfront development costs, without taking into account the future maintenance costs or the opportunity costs associated with the project. In fact, Galorath estimates that upfront development costs only account for 25% of the total cost of a software project - with most of the remaining 75% going to future maintenance and upgrades.
Let’s take a look at some ways to estimate and evaluate each one of these costs.
Upfront development costs
Upfront development costs are the easiest to understand as they represent the costs required to deliver the internal tool. Setting aside any additional special costs this project may need (such as additional software licenses), generally these costs will represent the developer resources needed to complete the project.
There are many simple formulas out there to estimate this, and most look something like this:
Upfront Cost = [# of developers needed] [avg # of hours or work-units per developer]
Some businesses that prefer to cost things in dollars may multiply this by average compensation paid per developer.
Upfront Cost = [# of developers needed] [avg # work-units per dev] [avg pay per dev]
The key is to understand the cost of the resources required to deliver the internal tool, regardless if it’s measured in time or dollars. Of course, there is also a balance that must be struck between the amount of time and resources spent, the quality of the tool delivered, and future costs. For example, spending more time and resources right now may result in less technical debt for future upgrades, but spending more time and resources right now also increases the opportunity cost for your team. It’s important to consider all of the tradeoffs you’re making, now and in the future.
Time required = [quality required] / [resourcing]
Future costs (maintenance / upgrades)
Although software might not “wear out” in the same way physical items do, it does become less useful over time, and there are usually issues to resolve after the initial version. When thinking about building custom internal software, it’s important to keep in mind that you’ll need to set aside resources to address future needs. These future costs can be broken down as follows:
Future costs = [Corrective maintenance] + [Adaptive maintenance] + [Enhancements]
Corrective maintenance refers to costs related to fixing software issues discovered after initial delivery (bug fixes). Generally 20% of future costs are attributed to corrective maintenance, although this can fluctuate depending on the quality of the codebase and level of technical debt.
Adaptive maintenance refers to the cost of adapting software to remain effective as the business and market changes. This can represent around 25% of future costs. Adaptive maintenance includes performance improvements or UX enhancements or any updates that are necessitated by the changing conditions. For example, a business may see a rapid increase in their market size or customer base, and now the internal tool they were using to look up customers is slow and difficult to use. The tool may need refactoring or features like pagination to keep the speed and user experience up to par.
Enhancements refer to costs due to continuing product innovations. These take up the lion's share of future costs: usually representing 50% or more. Enhancements differ from adaptive maintenance because they are chosen as a result of the business’s product strategy, and not driven by business conditions. For example, a business has just instituted a loyalty points program, and customers can earn VIP status and additional sales discounts by accumulating points. That business may want to upgrade their customer service internal tool with the ability to both view and award loyalty points — this would represent an enhancement of the existing internal tool.
So is there a way to actually measure future costs? It’s not likely that you’ll know which adaptive maintenance or enhancements may be coming for your tool years down the line, so a bottoms-up approach makes little sense.
Instead, you can use the fact that, for most businesses, your future costs are usually a fairly stable multiple of your upfront development costs (for like projects). We mentioned earlier that future costs are often estimated to be 3x the upfront development cost. This is a bit of a simplification, and various studies have been published showing a range from 2x to 10x:
Although there is a wide variety in cost ranges shown, this proves the point that future costs usually make up the bulk of the total build cost - at least 2x and sometimes 10x more than the upfront cost. You can try to estimate the future costs multiplier for a given product: over the lifetime of a similar product, how many more resources (developer-hours, etc) were needed to maintain and upgrade the product versus the initial development?
Future costs = [Upfront cost] [business’s future costs multiplier]
Opportunity cost
Opportunity cost is another overlooked cost as it represents the value of what your team could have accomplished had they not undertaken the project. Not only are you incurring the development costs of the project, but you’re also missing out on whatever output those developers would have otherwise created, and its associated value. Often, you’ll find that external facing products (for customers or partners) drive more business value than time spent on internal tools — but not always, so it’s important to measure what you’re trading off for any given project.
To measure opportunity cost of an internal tool project, it’s best to look at the impact(s) of the next-best project(s) that would’ve been delivered instead. Since estimating impact for opportunity cost is not much different than estimating impact for benefits, we’ll save the formulas for our next section, where we’ll talk about ways to look at the impact an internal tool can have.
Analyzing the benefits of internal tools
So now that we’ve talked about the costs, how do we figure out if the juice is worth the squeeze — if this particular tool has enough return on investment to justify building it? The exact impacts of any software project are innumerable and complex, so it’s important to distill it to a few key questions:
What does this tool enable?
How many people (internally) are impacted?
What are the gains that result from delivering this tool (almost always, these can be quantified in terms of speed, efficiency, or costs)
For example, a budding social media company wants to evaluate creating a tool for their customer service team to completely delete a user’s data (at their request). Currently, the customer service team has to make a ticket request to engineering to fulfill the request. An engineer then batches all the requests and runs a script to delete the data at the end of every business day. Customer service then reaches back out to the customer and closes the request.
To figure out the impact of this simple tool, let’s look at what it enables for the two internal employee groups: customer service and engineering. Customer service can now use the tool to immediately resolve the ticket themselves instead of making a ticket for engineering. Engineering no longer has to spend time batching the requests and processing them.
You can estimate the productivity or cost saving impact with the formulas below:
Productivity Impact = [# of people impacted] [avg. time savings per person]
Cost Savings Impact = [# of people impacted] [avg. cost savings per person]
Cost Savings Impact = [# of people impacted] [time savings] [cost per time period]
Let’s say this was a fairly common request and the 100-person customer service team gets ~1000 of these requests on a weekly basis. Currently, each request takes about 5 minutes to resolve, as the rep must create the ticket for engineering in a different system. With the new tool it’s expected to only take 1 minute to full resolution. By saving 4 minutes per ticket, the weekly impact of this new tool could be estimated at 4000 minutes saved or ~67 customer service hours. If reps were earning $30/hour, this internal tool could be estimated to save ~$2000/week or $8000/month. For simplicity, this example doesn’t use the total cost for an employee — when you factor in benefits, equipment, recruiting, office space, the total cost for an employee usually comes out to be approximately double their actual earnings.
We can measure the impact on engineering similarly. Let’s say it’s just the responsibility of a single engineer to batch requests and run the script each business day. It takes them 30 minutes of time, including context-switching to perform this task and get back to other work. On a weekly basis, this tool would save 2.5 engineering hours. If average engineer pay was $100/hour, the impact of the tool would be to save $250/week or $1000/month.
Although the impact on engineering is much smaller than it is for customer service, what’s important is to understand that in most cases, multiple teams are impacted by internal tools projects. When a tool is not built (or upgraded), the additional slack is often picked up by a number of other teams.
Internal tools: cost benefit analysis example
Let’s go through a quick example. We’re a mid-sized B2B software company, and we’re thinking about building an internal tool for onboarding customers. It would be used by three different teams: Sales, Account Management, and Solutions Engineering. It’s a fairly complex tool with different use cases for each team, and we estimate that it would take a team of 4 developers about 6 weeks to complete.
Therefore, our upfront development costs equals 960 developer hours (4 developers x 6 weeks x 40 hours per week).
Last year a similarly complex internal tool was built, and by tracking the development hours spent maintaining that tool since, we roughly estimated our future costs multiplier as 3 — for just the first year post-launch. Therefore, for future costs, we expect to spend approximately 2880 developer hours (960 hours x 3 multiplier) in the first year.
For the sake of simplicity, we’ll ignore opportunity costs for this example.
Now let’s calculate the expected benefit from building the tool. We think it will save our 100 person Sales team 6 hours per week each. For the 40 Account Managers we have, it’ll save them 12 hours per week each. And for our 20 Solutions Engineers, it will save them 8 hours per week each. So we can calculate the impact of building this tool in the first year as:
Impact on Sales: 100 people x 6 hours per week x 52 weeks = 31200 Sales hours
Impact on AM: 40 people x 12 hours per week x 52 weeks = 24960 AM hours
Impact on SE: 20 people x 8 hours per week x 52 weeks = 8320 SE hours
So our complete costs vs. benefits balance looks like this:
3840 Developer hours vs. ( 31200 Sales hours + 24960 AM hours + 8320 SE hours )
Since different teams have different goals, productivity, and costs, you have to weigh the relative value of their hours accordingly. An hour of developer time isn’t equal to an hour of a different team’s time — and could be worth more or less, depending on the company, its business strategy, and the market.
Internal tools cost benefit analysis conclusion
Although the above example is simple, the reality of comparing costs and benefits isn’t nearly that straightforward — a lot of nuance is left out and estimating hours spent or hours gained is never that easy. It’s important to remember that these formulas are guideposts to help you prioritize projects and see the whole picture, but they’re not definitive.
For that reason, it can be helpful to abstract the costs and benefits into something other than hours or dollars. At previous startups, I’ve used a product prioritization rubric that measured costs using a scale from 1 to 5, where 1 was a task that takes 1 engineer one day, and a 5 being a task that takes 4 engineers multiple sprints. We measured impact also on a 1-5 scale per impacted team, and used an “efficiency multiplier” for teams where we thought impacts might be larger due to efficiency or scaling gains. The simplicity of the rubric reminded us that these are all just estimates, but still allowed us to quickly compare projects against each other.
Remember that the goal of your cost-benefit analysis isn’t to calculate precise answers, but rather to make sure you’re asking the right questions to assess all of the costs and benefits.
Want a better way to build your internal tools? Build it with Internal - try it out for yourself below.
