What a lender's technology review actually looks at

For a period of my career I did technology reviews for a bank before it granted large business loans, and later for a business investment organisation. By the time I arrived the company had made its pitch and the relationship manager was keen. What the credit committee wanted was an answer to a question the pitch could not give them: if we lend this money, does the technology exist to earn it back?

That question is narrower than it sounds. Most of what follows comes from learning where the answer usually hides.

It is not a code review

The first thing to say is what the review is not. It is not an audit of code quality, and the lender does not care whether the engineers chose the right framework. A company can have beautiful code and no business, or ugly code and a very good one. The review is about risk to the money: whether the technology the forecast depends on exists, whether it can be kept running by people who will still be there, whether anyone else could take it over if they were not, and whether there is something in the technology that could stop the business at a moment nobody has planned for.

Ownership, people, continuity and hidden stoppers. Those four questions are the ones I kept coming back to, and they are the structure of the review.

Who owns it

The most common finding, and the one companies are most surprised by, is that they cannot show they own their own product. The founders wrote some of it before the company existed. A contractor wrote a part of it and was never asked to assign the rights. An early employee left without anyone checking what their contract said. None of this matters until it does, and the moment it matters is usually a sale or a refinancing, when a buyer's lawyers ask for the assignments and the company discovers there are none. I have written about this separately in "Who owns the code?", because it deserves its own piece.

For a lender this is a security question. If the loan is secured on the business and the business does not clearly own its main asset, the security is weaker than it looks. So the review asks for the assignments, not a statement that they exist. It asks for the list of open-source components and their licences, because a copyleft licence in the wrong place can oblige a company to publish code it thought was proprietary. And it asks what the product depends on that the company does not control: a cloud provider, a payment platform, a model provider, a component with a single supplier. Dependence is not a fault. Unexamined dependence is, and the AI supply chain has added a new layer of it that most companies have not yet looked at.

Who can keep it running

The second finding is almost as common. The product depends on one or two people, and the company has never said so out loud. Engineers call it the bus factor: the number of people who would have to be run over by a bus before nobody could maintain the system. In small technology companies it is often one, and that one is often a founder who is also the salesperson, the architect and the person who deploys on a Friday night.

The review does not ask whether these people are good. It asks what happens if they leave. Is there documentation a competent stranger could work from? Has anyone other than the author ever deployed the system? Are the passwords and keys somewhere the company controls, or in someone's head? I have sat across a table from a founder who answered the last question honestly, and watched him realise, as he said it, what the answer meant for the loan. The company had never thought to ask itself. It is also where the kind of CTO the company has matters: a brilliant builder who documents nothing is a risk the lender is being asked to carry.

Whether it is built to last

Only then does the review look at how the thing is built, and even then the interest is in evidence rather than opinion. Are there tests, and do they run before every release? Has anyone outside the team tried to break it? Are backups taken, and has a restore ever been tried? Not "do you have backups", which everyone answers yes to, but "when did you last restore from one, and how long did it take?" The difference between a hobby system and a professional one is not whether it works today. It is whether it can be trusted to keep working, and whether it can be recovered when it does not.

The review also asks what the company knows about its own technical debt, because debt that is not on a list is not in the budget, and the budget is what the lender is looking at. For connected products the questions become physical: how updates reach devices in the field, whether they are signed, whether a bad one can be rolled back, and what the company would do if it had to fix every unit it had ever shipped. I have covered that ground in the OTA problem.

Whether the technology can deliver the plan

The last part of the review ties the technology to the numbers, and it is where the three strands of a viability review, technology, market and finance, meet. A forecast is a claim about what the product will earn. The review asks how much of that revenue depends on features that do not yet exist, whether the customer evidence is for the product as it is or as it is planned, whether the biggest customers are on the same product as everyone else or on bespoke versions that will never scale, and whether the team the roadmap needs is the team the company has.

A forecast that rests mostly on unbuilt features is not a forecast. It is a roadmap with money attached, and every delivery risk in the review now applies directly to the numbers. That does not make the loan wrong. It makes it a different loan from the one that was pitched, and a single-figure forecast hides exactly this. The strategy questions belong here too: if the leadership team cannot describe the direction the same way, or the roadmap contains nothing that would change the company's position in three years, the money is funding a position rather than a plan. Strategic deficit is visible from outside if you know what to look for.

What the review gives the lender

At the end there was a written report and a recommendation, and the recommendation was rarely a flat no. More often it was a list: the assignments to obtain before drawdown, the documentation to produce, the second person to train, the restore to test. The value of the review was not the verdict. It was that the lender knew what it was lending against, and the company, often for the first time, knew what it did not have.

Most technology companies never see a review like this until money is on the table. That is the wrong time to find out. The questions are answerable months earlier, by the company itself, and the ones it cannot answer are the ones to fix first.

Three things worth taking seriously

For investors, lenders and boards: the free Technology Risk Snapshot asks these questions from your side of the table, answered from what the company has shown you, and gives you the questions to put to it before the next meeting. Where the answers justify it, independent technical due diligence is the full review.

For founders preparing to raise or borrow: run the review on yourself first. The assignments, the documentation, the second person and the tested restore all cost less before the question is asked.

For anyone reading a forecast: ask what share of the revenue depends on features that do not yet exist. The answer tells you what kind of plan you are looking at.

Which of these four questions would your company find hardest to answer with evidence rather than assurance?