How to Survive Tech DD

In English, might be easier: a short guide to how to survive technical due diligence.

If you are part of a software startup or are spinning up a new venture the time may well come when you are either seeking investment or are the target for acquisition. In this case the investor, generally a VC or angel, or acquirer will want to assure themselves of the technology on which their decision depends. As part of the 'deal' process they will set technical due diligence (tech DD) in train. This means that they will send somebody like me (possibly even me) supported by a small team, to check you out. Now, however slowly the commercial preliminaries have been, and however protracted the discussions with potential investors, I guarantee that this will all happen suddenly and in a terrible rush. Why? I do not know, but you might as well be ready. Just so you are fully in the picture, your management partners will all be engaged in commercial and financial discussions, so if you are lead developer, CTO or whatever, you are on your own.

So, what are the tech DD team looking for? Well first, understand that they are working for the potential investor or acquirer who is making their move based on your business plan (or less straightforwardly, on their interpretation of your business plan). Tech DD is principally oriented to establishing whether the technology assets - people, processes and products - that you possess are consistent with the business plan, or whether there are hidden risks and uncertainties that might impinge on the business plan and hence affect the predicted return on investment. Remember, early stage tech is very risky, so to secure investment you will have had to promise high multiples and rapid growth which will certainly stress any technology decisions you will have made. Tech DD is forward-looking not retrospective. Here is roughly what you need to be ready for.

First question for tech DD, are the technology team smart? How good are the CTO and the key developers? Will there be a need to tie these people in, or is it no problem if they leave? Does the  senior team possess the skills necessary to take the organisation beyond where it is now? Though the tech DD team appear friendly, they are assessing you. The investors will want to know if you should be replaced. It is likely that the next stage of growth will require management and organisation significantly beyond that required to get your technology to its current state, do you have the necessary skills or experience? If not, are you at least aware of what might be needed?

Next question, what is the state of the development organisation? Is there an organised, version-managed, code base? Are there tests? Are there established procedures for issue and bug tracking, taking particular account of user-feedback? Is there some management of requirements and does this align with the technical roadmap that forms part of the business plan? What are the key quality metrics and how are they monitored? Is there some documentation or means of ensuring the organisational memory for key decisions? Is this information managed securely? Does the organisation appear 'tight' and well managed?

Moving on to the architecture. Is there a shared picture of the architecture and its trajectory? Does the CTO and the key developers appear to have this clearly in mind? Are they on top of the key 'volumetric' drivers: performance, transactions, resource consumption, and so on. Can the architecture and the business plan be reconciled? Is the architecture flexible or adaptable to changing business imperatives and is it scalable to accommodate the business plan as it unfolds? Are there any obvious discontinuities or points where major costly changes to the architecture might be required? What are key dependencies and risks (these include quasi-commercial risks associated with incorporation of 3rd party commercial products and services within the architecture), and what steps have been taken to identify them and address the consequences? Have reliability, security, privacy and regulatory compliance been covered off?

Looking beyond the product or service to the competitive landscape, tech DD will want to establish whether the development team has made an accurate assessment of the technical capabilities of its competitors. Are the benchmarks and assumptions valid? Is there any key intellectual property or valuable know-how incorporated in the product or service? Does the team know what it is and is it adequately protected (a cross-reference may be made here to the legal DD team)? Are there any potential issues with use of open source or similar materials? How quickly and at what cost could a determined and well resourced competitor reproduce the product or service? Are there any other steps a competitor could take to interfere with, or block, business opportunities?

The tech DD team will want to assure themselves that what they are being told is true. They will want to take a look at some of the code, the tests, the documents, logs, and so on. They will want to know that your product is not just 'slideware', and touching, feeling or smelling a 'sample' is the best way to do that. Finally, they will be called on to make a judgment, on which somebody elses money rests, they will need to believe in your product or service not as a business proposition, not their call, but as a technical one. The judgment will necessary be holistic, you will have had to be convincing.

To survive tech DD you will have to be prepared, and given, as I said, this is likely to happen suddenly and rapidly, there is no time like the present! After all you did not have anything planned for this week did you?