Less software, not more
The default response to operational drag is to add another tool. Most of the time, the higher-leverage move is to remove one.
Walk into most growing service businesses and you will find a tool sprawl: a scheduling app, a CRM, a routing tool, a separate inbox, a separate forms tool, a separate customer-record system, a billing tool, a notes tool — and a founder or operator quietly holding the whole stack together with attention.
The standard response to operational drag is to add more software. The standard outcome is more drag.
The stack tax
Each tool in an operational stack carries a tax that compounds:
- Reconciliation tax. The same customer exists in multiple systems. Updating one does not update the others.
- Context-switching tax. The operator runs the day across several windows, each with its own model of what "the customer" or "the job" means.
- Configuration tax. Each tool needs to be configured, kept current, and onboarded into for each new team member.
- Integration tax. Every tool that needs to talk to every other tool is a maintenance surface that quietly grows.
- Mental-model tax. The biggest cost. The operator has to hold a working model of every tool in their head.
By the time a business is running on a stack of eight tools, the stack itself is a significant percentage of the operator’s daily load. The tools were added one at a time to solve specific frictions. They are, collectively, the largest source of friction.
The leverage move is subtraction
Adding a ninth tool to fix the drag from the first eight is the obvious play and the wrong one. The higher-leverage move is to find the tools you can subtract and the surfaces that can be collapsed.
Subtraction in practice usually looks like:
- One operational surface that holds the customer, the job, and the schedule — not three.
- One inbox where the operator triages everything inbound, not five with different rules.
- One source of truth for what is happening today, not a chat channel plus a calendar plus a whiteboard.
- One audit trail where the operator can answer "what happened?" without opening multiple tabs.
This is unglamorous infrastructure work. It looks less like "AI for X" and more like "an honest operating system for service work."
Why the market builds the opposite
The market structure rewards point tools. A SaaS company that does one thing well is easier to fund, easier to position, easier to sell. The buyer pays the integration cost. The fragmentation is not a bug from the vendor’s perspective — it is a feature of the market.
The buyer’s calculation is different. The buyer wants the operational result, not the optimal point tool for each sub-problem. From the buyer’s seat, a single coherent operating surface that does eight things 80% as well as the best-in-class point tool is usually a better business.
Closing
The advice we keep returning to with operators: before adding another tool, ask whether you could remove two. Usually yes.
More writing.
Daily use over demo velocity
Software optimized for the first five minutes is rarely the software that holds up in the second year. A short note on what we build for instead.
Supervised automation for real operations
The line between automation and autonomy is not academic — it determines whether a system is leverage or risk. A working definition.