Which Internal Tools Are Worth Building

Internal tools have the worst return distribution in software. A few are transformative. Most are built, used briefly, and quietly abandoned — and the abandoned ones still cost maintenance, still hold data someone will eventually need, and still occupy a line in the mental model of how the company works.

The skill is not building them well. It is choosing which ones to build.

The test

Four questions. A tool needs a convincing answer to all four.

1. Is it a recurring cost, or a one-off annoyance?

Automating something that happens once a quarter is almost never worth it, no matter how irritating it is when it happens. Frequency multiplied by duration is the number that matters, and people consistently overweight irritation relative to frequency.

2. Is the process settled?

Automating a process that is still changing every few weeks means rebuilding the tool every few weeks. Wait until the shape has stabilised. “We do it slightly differently each time” is a signal to keep doing it manually a while longer.

3. Is the pain shared?

A tool that helps one person is worth roughly one person’s time saved. A tool that removes friction for everyone compounds. Both can be worth building, but they are worth very different amounts, and the single-user tool should be correspondingly cheaper to build.

4. Will someone own it?

Every tool needs a person who notices when it breaks and cares enough to fix it. Without that, you are building something that will fail silently and be discovered at the worst possible moment. If no owner will volunteer, that is information about how valuable it really is.

Prioritise by the frustration curve, not the request queue

The tools people ask for are not the tools with the best return. People request what is annoying; the highest-return tools address what is slow, which is much less viscerally irritating and much more expensive.

A better prioritisation:

First: things that block other people. Anything where someone waits on someone else. Blocking work costs more than its duration because it fragments attention on both sides.

Second: things done daily. Daily frequency compounds fast. Even a five-minute saving is meaningful annualised across a team.

Third: things where mistakes are expensive. A tool that makes a costly error impossible pays for itself the first time it prevents one, and it prevents an unbounded number after that.

Fourth: things that only one person can do. Not for efficiency — for resilience. Single points of failure in a process are a business risk before they are an inconvenience.

Notice that “the thing everyone complains about” appears nowhere. It is often on the list anyway, but complaint volume is a poor proxy for cost.

Build small, deliberately

The strongest bias to hold: build the tool, not the platform.

A tool that does one job well ships in days, gets used immediately, and is cheap to throw away when the process changes. A platform that anticipates every related need takes months, launches into a process that has moved on, and is too expensive to discard so it lingers.

This is not a compromise position. Small tools are genuinely better for internal work, because the process they support is going to change and the tool needs to be cheap enough to change with it.

Practical implications:

• One tool per job. Resist consolidation until you have three that genuinely overlap.
• Hard-code what is currently true. Configuration is a decision deferred at the cost of complexity.
• Use the boring stack. Internal tools are not where you learn a new framework.
• Skip the polish that does not affect the work. Internal users will trade aesthetics for speed every time.
• Write down how to turn it off. Genuinely — the successor should know what depends on it.

Reasons to reject that sound like reasons to build

“It would be nice to have.” Nice-to-have tools do not get used, because the manual path is already habitual and switching costs something. Build the tools people need, not the ones they would appreciate.

“We could sell this later.” Almost never true, and the pursuit of it inflates scope enormously. Build for your own use. If it turns out to be sellable, you will find out from the internal usage.

“It’s only a small build.” Small builds still carry maintenance, still need an owner, and still occupy attention. The build is the cheapest part of a tool’s lifetime cost.

“Everyone else has one.” Your process is not their process. The tool that works for them may encode assumptions that do not hold for you.

The tools that consistently pay off

Across the work we have done, a few categories come up again and again:

• Reconciliation tools — anything that compares two systems that should agree and surfaces where they do not.
• Review queues — a good interface for handling the exceptions an automated process kicks out.
• Status visibility — a single view of where things are, replacing the round of messages asking.
• Bulk operations — doing to two hundred records what the vendor tool makes you do one at a time.

What these have in common: each removes a recurring coordination cost rather than adding a capability. That is the shape to look for.

We build internal tools at the size the problem actually warrants. See how, or read about when a spreadsheet has stopped being enough.