Technology due diligence

Before a lender, an investor or an acquirer commits money to a technology company, someone has to say whether the technology is real: whether it exists as described, whether it can be kept running by people who will still be there, whether the company actually owns it, and whether anything in it could stop the business at a moment nobody has planned for. For a period of my career I was that someone, carrying out technology reviews for a major UK bank before it granted large business loans, and later for a business investment organisation. This is the same review, offered directly.

Who it is for

Lenders and credit committees deciding whether to lend to a technology company, or to a company whose plan depends on technology. Investors before a round, and acquirers before a purchase, who want a technical opinion that is independent of the founders and of the deal team. Boards of companies that are about to raise, sell or refinance and want to find the problems before the other side's advisers do. And occasionally the company itself, when a leadership team wants a plain second opinion on a product or a platform before a big decision.

What the review looks at

It is not a code review, and the framework choices are not the point. The review is about risk to the money, and it follows four questions. Who owns it: the assignments from founders, contractors and former employees, the open-source components and their licences, and what the product depends on that the company does not control, including its AI supply chain. Who can keep it running: the people the product depends on, what happens if they leave, whether a competent stranger could work from the documentation, and whether the keys are somewhere the company controls. Whether it is built to last: testing, security, the update path, the state of the infrastructure, and the technical debt that is about to become expensive. Whether the technology can deliver the plan: the gap between what the forecast assumes and what the platform can actually do at the volumes, in the markets and on the timescale the plan requires.

Where the product is a connected device, the review also covers device security, over-the-air updates and the regulatory position (the EU Cyber Resilience Act and UK PSTI), because those are where a hardware company's hidden stoppers usually sit. Where AI is part of the product, it covers what the company really owns, what it depends on and what happens if that dependency changes price or disappears.

How it works

A scoping call to agree what the decision is and what evidence the company can make available. Then typically one to two weeks of my time: document review, interviews with the technical leads and, where appropriate, hands-on inspection of the systems, the repositories and the deployment. I ask for the assignments, not a statement that they exist; for the test results, not a description of the process; for a deployment done by someone other than the author. The output is a written report that says plainly what is sound, what is at risk, what it would cost to fix and how long that would take, with a clear recommendation and the questions the deal team should put to the company before signing. Findings are ranked by their effect on the decision, not by how interesting they are technically.

Fixed price, agreed at scoping, so the deal team has a number it can put in front of a committee and a guarantee it will not drift. What sets the price is the size and complexity of the target (engineering headcount, number of products and platforms, how much is in the cloud and how much on devices) and how deep the security testing needs to go. Most reviews complete within three weeks of the first call, depending on how quickly the company can produce what I ask for; delay is usually on that side, which is itself a finding.

Who does the work

I do. The timings above are for one senior reviewer, which suits a target of roughly twenty to five hundred people with a small number of products or platforms, and it is what most lending and investment decisions at that scale need: an experienced engineer who has run companies like the target, reading the evidence and talking to the people. Where the scope is larger, a group with several platforms or a product range across many markets, the review is split into phases and priced accordingly, or I bring in specialists, for penetration testing or a licence audit of a large codebase, working to my brief and reporting through me, so the lender still gets one opinion and one name on it. I say which at scoping, and if the job needs a firm rather than a person I will tell you that too.

I am based in Leeds and work on site or remotely, in the UK and internationally.

Why me

I have sat on both sides of the table. I have done these reviews for a bank and for investors, and I have run product development in the kind of company they review: connected hardware, firmware, apps and cloud platforms sold into several markets with different rules. I am a Chartered Engineer, I still build, and I have held COO and CEO seats in listed technology companies, so I read a technology plan as an operator as well as an engineer. That combination is what lets a review say not only "this is a risk" but "this is what it would take to fix, and whether the team in front of you can do it".

Before you commission a review

The free Technology Risk Snapshot takes ten minutes, answered from what the company has shown you so far, and gives you the risks and the questions to put to it before the next meeting. If the answers come back clean and evidenced, you may not need me. If they do not, you will know what to ask for.

Reading

• What a lender's technology review actually looks at: the four questions and where the answers usually hide.
• Who owns the code?: the most common finding, and why companies are surprised by it.
• The AI supply chain: the new layer of dependence most companies have not yet examined.
• Where technical debt becomes expensive.