Which Internal Tools Are Worth Building

Internal tools have the worst return distribution in software. A few are transformative. Most get 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 isn’t building them well. It’s choosing which ones to build.

The test

Four questions. A tool needs a convincing answer to all of them.

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 does happen. Frequency times duration is the number that matters, and people consistently overweight irritation relative to how often it actually occurs.

Is the process settled? Automating something that’s still changing every few weeks just means rebuilding the tool every few weeks. Wait until the shape has stabilised. “We do it slightly differently each time” is a sign to keep doing it manually a while longer.

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’re worth very different amounts, and the single-user tool should cost correspondingly less to build.

Will someone own it? Every tool needs a person who notices when it breaks and cares enough to fix it. Without that you’re building something that will fail silently and get discovered at the worst possible moment. If nobody will volunteer to own it, that tells you something real about how valuable it actually is.

Prioritise by the frustration curve, not the request queue

The tools people ask for aren’t the tools with the best return. People request what’s annoying, but the highest-return tools address what’s slow, which is much less viscerally irritating and much more expensive.

A better order to work in: start with things that block other people, anything where someone sits waiting on someone else, since blocking work costs more than its raw duration because it fragments attention on both sides. Then things done daily, where even a five-minute saving becomes meaningful once you annualise it across a team. Then things where mistakes are expensive, since a tool that makes a costly error impossible pays for itself the first time it prevents one and keeps paying after that. And finally things that only one person can do, not for efficiency but for resilience, because a single point of failure in a process is a business risk before it’s ever an inconvenience.

Notice that “the thing everyone complains about” doesn’t appear anywhere in that list. It’s often on it anyway, but complaint volume is a poor proxy for actual cost.

Build small, deliberately

The strongest bias worth holding here is to 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 tries to anticipate every related need takes months, launches into a process that’s already moved on, and ends up too expensive to discard, so it lingers instead.

This isn’t a compromise position. Small tools are genuinely better for internal work, because the process behind them is going to change, and the tool needs to stay cheap enough to change with it. In practice that means one tool per job, resisting consolidation until three genuinely overlap. It means hard-coding what’s currently true rather than adding configuration for a decision you haven’t actually made. It means using the boring stack, since internal tools are not where you learn a new framework, and it often means skipping the cloud infrastructure entirely when a single operator on one machine was never going to need it. It also means skipping the polish that doesn’t affect the work, because internal users will trade aesthetics for speed every time. And it means writing down how to turn the tool off, so whoever inherits it knows what depends on it.

The same discipline, cut to one path before anything else, is what makes an AI product shippable in weeks instead of quarters. We lay out exactly how in how to scope an AI MVP that actually ships.

Reasons to reject that sound like reasons to build

“It would be nice to have” rarely survives contact with reality. Nice-to-have tools don’t get used, because the manual path is already habitual and switching costs something real. Build the tools people need, not the ones they’d merely appreciate.

“We could sell this later” is almost never true, and chasing it inflates scope enormously. Build for your own use first. If it turns out to be sellable, the internal usage will tell you.

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

“Everyone else has one” assumes your process matches theirs. It usually doesn’t, and the tool that works for them may encode assumptions that don’t hold for you at all.

The tools that consistently pay off

A few categories come up again and again across the work we’ve done. Reconciliation tools, anything that compares two systems that should agree and surfaces where they don’t. Review queues, a good interface for handling the exceptions an automated process kicks out. Status visibility, one view of where things stand, replacing the round of messages asking. And bulk operations, doing to two hundred records what the vendor tool only lets you do one at a time.

What these have in common is that each removes a recurring coordination cost rather than adding a new capability. That’s the shape worth looking for.

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