A rule of thumb for internal tools as real products

Somewhere between a principle and a habit sits the useful kind of rule: right most of the time, and wrong in ways you'll notice straight away. This is one of those.

The software your own staff use all day deserves the same care as the software you sell. It usually gets a fraction of it, on the theory that a captive audience can be trained. They can. They'll also quietly build a better tool in a spreadsheet.

THE CAPTIVE AUDIENCE FALLACY

Internal users can't leave, so their frustration never shows up as churn. It shows up as slower work, more errors, and a hiring problem nobody connects back to the tooling. The feedback loop that keeps customer-facing software honest simply doesn't exist here, so quality drifts down until someone measures it.

The people using it all day also stop reporting problems, which is the part that fools everyone. Silence reads as satisfaction. It's usually resignation. If nobody's complained about the internal tool in six months, that's worth investigating rather than celebrating.

WHERE THE RETURN IS

The arithmetic is unusually friendly. Twelve people, all day, on one screen: shaving thirty seconds off a task performed forty times a day is an hour a week each. You rarely get returns that clean on customer-facing work, and you never have to guess at the usage numbers.

There's a second return that's harder to put a number on. Good internal tools make the process legible, and legible processes can be improved. Bad ones hide the process inside habit and tribal knowledge, and you can't improve what you can't see.

Checked against laboratory sample tracking: at around 20,000 samples a month it holds comfortably. It'd start to wobble an order of magnitude higher, where the fixed costs it ignores stop being small.

WHAT GOOD LOOKS LIKE HERE

Not polish. Internal tools can be plain and should be dense. The people using them are experts and don't need onboarding wizards or generous whitespace. What they need is speed, keyboard access, honest error messages, and states that match the job.

The single highest-value feature is usually undo. Expert users work fast and fast users make mistakes, and the difference between a tool people trust and one they're careful around is whether a wrong click is recoverable.

The rule would have caught a batch was reported before its confirmatory run had finished and didn't, because nobody applied it to the integration written under deadline. That's the usual story. The heuristic is fine, the coverage isn't.

WHERE IT GOES WRONG

• Error messages written for the developer rather than the person who has to act on them.
• A tool nobody has complained about in six months, mistaken for a tool that works.
• Designing for onboarding when the same twelve people have used it daily for three years.
• No undo, so expert users move slowly on purpose to avoid mistakes they can't take back.

If a dozen people use it all day, it's a product. Fund it like one.

WHEN THE RULE FAILS

Treat it as a prompt to think, not a substitute for thinking. Its job is to stop the same conversation happening a fourth time, not to end it.