What an internal tool costs, and when it pays for itself

Nobody gets promoted for building an admin panel. Internal tools sit in the backlog behind anything customer facing, and they stay there, while the cost of not having them is paid every week in small amounts by people who have stopped mentioning it.

Here is how to work out whether one is worth building, in numbers you can take to whoever signs.

The calculation

Four inputs, and you can get all of them in an afternoon by asking the people doing the work.

• How many people touch this process
• How many hours a week each of them spends on it
• What an hour of their time costs, fully loaded
• What proportion of that time the tool actually removes, which is never a hundred per cent and is usually between fifty and eighty

Multiply, annualise, compare to the build cost. An internal tool between one and a half and four lakh needs to save roughly four to ten hours a week across the team to pay back inside a year. In our experience most processes that have annoyed people enough to be mentioned are saving considerably more than that.

The savings nobody counts

The hours are the easy part and they understate it. The bigger returns are the ones that do not appear on a timesheet.

• Errors prevented rather than found. One wrong rate caught at entry is worth more than a month of checking.
• Decisions made this week instead of next. Latency in information is a real cost and nobody measures it.
• The thing that stops being a single person's job. Resilience has a value and you discover it when they resign.
• Work people stop avoiding. A process that is painful gets done late, and late has downstream costs.

When not to build

We talk clients out of internal tools regularly, and the reasons are consistent.

• The process is about to change. Build the tool after the change, not before.
• It is one person's preference rather than a team's problem. A tool for one enthusiastic user becomes shelfware when they move on.
• A product already does it well. Buy it. Configure it properly. Move on.
• The real problem is that nobody has decided who owns the process. Software will not decide that for you, and automating an unowned process just makes the confusion faster.

Start smaller than feels sensible

The most common failure is not a bad build, it is too large a first build. A tool with forty features takes four months, by which time the people who asked for it have lost interest and built a workaround. A tool with eight features takes three weeks, gets used, and tells you exactly what the next eight should be.

Everything we have built that is still in daily use years later started smaller than the client originally wanted. Everything that quietly died started bigger.