Buy the Workflow, Not the Software
The most reliable protection a software business has is not in the product. It is in the cost the customer would incur to change how they work.
Every argument about software moats eventually arrives at switching costs, and most of them stop there. It is worth going one step further, because there are two very different things hiding under that phrase.
There are switching costs that live in a contract, and switching costs that live in an operation. The first end when the contract does. The second have to be paid by someone, in disruption, before any saving is realised.
Product usage versus workflow ownership
Product usage means people open the software and it does something useful. It is measurable, it looks healthy in a data room, and it can be replaced by anything that does the same thing for less.
Workflow ownership means the software is the shape of the work. Procedures reference it. Training assumes it. Handovers pass through it. Auditors expect it. The people who would have to approve a change are not the people who bought it.
Software can be replaced. Replacing a deeply embedded workflow is a change programme, and someone has to be willing to run it.
This distinction matters more as software gets cheaper, not less, because the reproduction cost of the product falls while the reorganisation cost of the customer does not. A competitor with a cheaper, better tool still has to persuade an operations director to accept a bad quarter.
How to tell the difference
Four questions separate the two reliably, and none of them can be answered from usage statistics.
What stops if it disappears?
Not “what gets harder” — what actually stops. If the answer is that a report is produced differently, this is a tool. If the answer is that a shift cannot be closed, an order cannot ship or an invoice cannot be raised, this is a workflow.
Who would have to approve a replacement?
A tool is replaced by whoever owns the budget. A workflow needs operations, compliance, training and often a works council. The length of that list is a good proxy for the depth of the moat.
What was configured, and by whom?
Years of accumulated customer-specific configuration, rules and exceptions represent labour the customer paid for and would have to pay for again. That is a real cost even when the software itself is unremarkable.
Does anything downstream depend on its output?
Integrations, regulatory filings, customer-facing documents and other systems that consume the output all extend the blast radius of a switch far beyond the original purchase.
What this means in diligence
Workflow embedment is one of the few properties that reliably survives a cheap rebuild, and it is systematically under-evidenced in transactions — because it lives with the customer rather than in the target’s repository.
It is also the property most often asserted without support. “Mission critical” appears in almost every management presentation. The useful follow-up is simply: critical to which specific process, and what happens to that process on the day the system is unavailable?
And for operators
If cheap software is going to erode the product differentiation of a business, the strategic response is not usually to build faster. It is to move deeper into the customer’s operation: take over more of the process, absorb more of the exception handling, become the system of record rather than a participant in it.
That work is unglamorous and it is the opposite of what an engineering organisation instinctively wants to do with a productivity gain. It is also the version of the response that still matters in five years.
The neighbouring question — whether the whole category can be absorbed by a platform, in which case workflow depth buys time rather than safety — is the hyperscaler test.