Technology Due Diligence Beyond Software
The technology question in a non-software business is rarely about the product. It is about the processes that run the company, and how much of them a competitor is about to automate.
Technology due diligence is commissioned reliably when a target sells software, and skipped almost as reliably when a target makes something physical or sells professional work.
That was defensible while technology and software were the same thing. It is no longer, because the processes that run a manufacturer, a logistics business or a service firm are now the part that AI and automation act on most directly.
What is actually being underwritten
In a non-software target, the value-creation plan usually contains at least one of the following: margin improvement, throughput improvement, headcount efficiency, a multi-site rollout, or an integration after a bolt-on. Every one of those is an operational claim, and every operational claim is carried by systems and processes somebody has to be able to describe.
What actually runs this company, and what would happen to the plan if that stayed exactly as it is?
The answer is frequently more informative than the financial model, because the model assumes an operational change and the systems determine whether it is possible.
The questions worth asking
Six lines of enquiry cover most of what matters, and none of them require the target to sell software.
What runs the company
Which processes are load-bearing, what carries them, and how much of that is manual, email-based, spreadsheet-based or dependent on one person’s knowledge. The workarounds are usually the most informative artefact in the building.
Where the AI upside actually is
Not a list of use cases. Which specific knowledge-work processes — quoting, planning, documentation, quality analysis, service handling, administration — could economically compress, what that is worth, and what has to be true for the saving to be realised rather than absorbed.
Where automation pays and where it does not
Physical automation, machine vision, robotics and process control have real returns and real failure modes. The cases that do not pay should be named as clearly as the ones that do; a diligence that only finds upside has not been done.
Where the operational risk sits
Which systems are business-critical, what a day without them costs, what the fallback is, and whether anyone has used it. Cyber exposure belongs here too — read as an operational risk with a number attached, not as a control checklist.
Whether the data is usable
Industrial businesses often have decades of operational data and no ability to use it: different systems, inconsistent identifiers, no lineage, nothing joined. The gap between having data and being able to act on it is where most industrial AI plans quietly die.
What technology investment the plan requires
An ERP nearing end of support, an unsupported control system, or a data platform that does not exist yet are all capital requirements. If they are not in the model, the model is wrong by that amount.
Who captures the compression
The most consequential question in an industrial diligence is also the least often asked. If AI halves the cost of engineering documentation, quoting or service dispatch, the company does not automatically earn more.
The gain may reach the customer as a lower price, because competitors received the same tools at the same time. It may reach an entrant who never carried the old cost base. It may reach a platform supplier who prices the capability at what it is worth rather than what it costs. Whether any of it reaches the company depends on the structure of the market, not on how well the company implements.
A productivity gain everyone receives belongs in the cost baseline, not in the investment case.
What the physical side protects
The reverse is also true, and it is one of the more useful findings a diligence produces. Physical integration, installed equipment, service networks, certification and safety approval do not respond to cheaper software. In an industrial target these are frequently the most durable assets on the balance sheet, and they are rarely written up as such because they do not look like technology.
A business whose advantage sits in the physical layer can adopt AI aggressively in its operations while remaining hard to displace — which is a considerably better position than a software business with the same ambition and no physical anchor.
How this differs from an IT audit
An IT audit describes the estate: what exists, what it costs, what is unsupported, what the risks are against a control framework. That work is useful and it is not this work.
This asks a commercial question with a five-year horizon: what technology does to the economics of this business during the holding period, whether the value-creation plan can actually be executed by this organisation, and what it would cost if the assumptions underneath it are wrong.
The output is not a maturity score. It is an argument about the plan — which is what technology and AI due diligence is scoped to produce, and why the operational half of it belongs in every non-software transaction rather than in some of them.