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. The reviews I did for the bank came before AI features and software bills of materials were common, but the same questions apply to them.

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.

Who owns it, who can keep it running, whether it is built to last, and whether it can deliver the plan: 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.

How ownership goes missing

In the UK, copyright in code usually belongs to whoever wrote it. The main exception is an employee writing it in the course of their employment, where the employer owns it by default. That rule hides three ways ownership goes missing.

The first is work done before the company existed. Founders write the first version at the kitchen table, then form the company, then carry on. Nothing transferred the kitchen-table code to the company. It still belongs to the person who wrote it, who is now a shareholder, a director, and possibly, in a few years, an ex-founder with a grievance.

The second is contractors. A contractor is not an employee, and the default is that they keep the copyright in what they write unless the contract assigns it. The client may have some right to use the work, but that is not ownership, and it may not be enough for a buyer or a lender. Many early contracts, especially the ones agreed by email with a friend of a friend, say nothing. A good deal of software in small companies is, strictly, still owned by freelancers who have long since forgotten it.

The third is the things nobody thinks of as code: the data an AI feature learned from, the designs, the documentation, the firmware in a device that a contract manufacturer’s engineer adjusted on the production line. Each may have an author with rights of their own unless those rights were assigned. For AI features the question has a second edge, because the company also needs the right to use the data it trained on, and data has a way of arriving without its permissions.

Why it matters at the worst moment

None of this stops the company working. The product runs, customers pay, nobody asks. The question arrives with money: a loan secured on the business, an investment round, an acquisition. At that point someone’s lawyers ask for the chain of title, the documents that show every contribution was assigned to the company, and the company discovers it has a chain with missing links.

The fix at that point is to go back to every contributor and ask them to sign. Most will. Some cannot be found. One or two, having worked out what the signature is worth to the deal, will name a price. I have watched deals slow to a crawl over exactly this. The company that had done the paperwork five years earlier, for the cost of a template and an afternoon, would have walked straight through.

What the review asks for

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. 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 many companies have not examined.

The second half of ownership is what the company has taken in. Modern software products commonly incorporate open-source components, each governed by a licence. Most licences ask little more than attribution. Some, the copyleft licences, can require software combined with them to be released under the same terms, depending on the licence and on how the software is distributed or, for some licences such as the AGPL, offered to users over a network. That is a fine bargain for a community and a bad surprise for a company whose business is selling the software.

A review asks for a list of components and their licences, a software bill of materials, and whether the company has a policy about which licences it accepts. Most small companies have neither. With the right tool the list can often be produced quickly; deciding what to do about the one component that should not be there can take longer. The same list is the starting point for knowing what else the product depends on, which is the next question any reviewer asks.

What good looks like

Good is boring. Every founder, employee and contractor has signed an assignment of the intellectual property in their contributions to the company, including anything from before incorporation. The signed copies are in one place. There is a current list of third-party components and their licences, and someone owns the job of keeping it current. Where the product depends on something the company does not own (a platform, a model, a supplier), the dependence is written down with what the company would do if it changed.

A company can put all of that in place in a few weeks, for very little money, at any time before it is needed. Doing it after the question has been asked costs more, takes longer, and occasionally cannot be done at all. It has nothing to do with how well the code is written.

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 (chapter 2) 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 (chapter 9), 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 chapter 13.

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 (chapter 25) 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 (chapter 20) 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.

Worth taking seriously

For investors, lenders and boards: ask to see the signed IP assignments, the licence list and the date of the last tested restore, not assurances that they exist. Each takes minutes to produce if it is in place.

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.

I am an engineer, not a lawyer. The principles above are the ones a technology reviewer works to; for the position of a particular contract or contributor, ask someone who is.

This is a sample chapter from What It Takes: Technical leadership for CTOs, founders and boards, coming soon. References to other chapters are to the book. More about the book, or follow my writing to hear when it is out.

What a lender’s technology review actually looks at