When a tool starts making work, it's stopped being a tool

Every ops team we talk to has some version of the same complaint. It's rarely about the price of any one tool. It's about the twelve of them, and the person whose job has slowly become making them talk to each other.

That's the thing worth naming. A tool earns its keep by removing work. When it starts generating work instead — copy-paste between tabs, weekly CSV exports, a Zap that breaks every third Tuesday, a Slack channel dedicated to reconciling two systems that disagree — it's no longer a tool. It's a coworker you're paying a subscription for.

This Medium piece puts it well: SaaS fatigue is the cognitive overhead of stitching tools together, not the line item on the invoice. We think that's exactly right, and it changes how you should evaluate your stack.

The audit that actually matters

Forget the annual license review. Try this instead. For each tool in your stack, ask two questions:

1. What work does this remove? 2. What work does this create?

The first answer is usually easy. That's why you bought it. The second is where the truth lives. It shows up as the daily standup item nobody wants to own, the onboarding doc that keeps growing, the exception handling nobody documented because it lives in one person's head.

If the second list is longer than the first, the tool is upside down. It might still be worth keeping. But you should know that's what you're paying for.

The fit gap is the real cost

Most SaaS tools are built for the median customer in their category. If your workflow sits close to that median, the tool fits and the work-generated column stays short. If your workflow is even slightly non-standard — and most real businesses have at least one process that isn't — you end up bending your operation to match the tool's assumptions.

That bending has second-order effects. Staff invent workarounds. Data lives in two places. Reports require a human translator. New hires spend their first month learning your specific version of a tool that was supposed to be self-explanatory.

This is the point where a custom build starts to make sense, and not before. Not because custom is better in some abstract way. Because at that point, you're already paying the cost of a custom system in human time. You're just paying it forever, in small daily increments, instead of once.

What to do about it

Start with the boring stuff. The workflow that eats an hour a day, five days a week, is worth more attention than the shiny process you might redesign next quarter. Look for the tool that quietly flipped from asset to liability. Sometimes the fix is a small custom layer between two things you already own. Sometimes it's admitting a tool doesn't fit and replacing it.

Either way, the question isn't build vs. buy. It's whether the thing in front of you is still removing work. If it isn't, something needs to change.