Tech Due Diligence Process
How to do it well
Every successful startup should go through Due Diligence process and Technical due diligence is an important part of it. Basically, it is the process of evaluating the technology, architecture, processes and security.
You can be sure that investors, buyers, or potential partners will want to take a close look under your technology’s hood. Usually, you are supposed to prepare many documents which need to be uploaded into the DD room. This has historical reasons. Before the digital time, all the documents (Financial, billing, HR, etc) were provided into the DD room for evaluating. These days, it’s usually not a physical room but Google Drive or any sharable file storage.
Directory structure
I think the best approach is to create a simple directory structure and then to create all the necessary documents in them. The most important is to give a global tech overview. It should answer questions like — What is your product? Is it a client side application? Is it server service? Is it a process? Don’t go into the details at the beginning. Forget them. Giving a quick overview and keeping it simple is what’s important here.
Components
Divide the whole project into components such as clients, search, analytics, utilities. You can look into your git repos and think about them as components. It really depends on you. Of course, you should be more detailed when you are documenting the most important components.
Costs
Bring the numbers here. Well, you don’t need to go into the details here, because Financial Due diligence does. However, you should go through all of your third party services (Clouds, CDNs, Databases, Data transfers) and summarize how much this tech costs. Sometimes, it is necessary to talk about tech team salaries too. Do not reveal the number without asking if it is really necessary.
Dependencies
Software dependencies. What packages, modules, services do you need to run / build your product? Name them, list them. I understand it’s not easy to list all your packages because every package has its own dependency. So it’s actually a dependency tree or dependency hell. Don’t forget to mention the dependency on third party services. (Clouds, CDNs. etc).
Growth & Potential
All the directories and all the documents are about current status except this one. This part should give answers for the following types of questions: What are your plans for the future? What features will you implement? Which new technology will you use? What is your technology potential? What optimizations are you working on?
Infrastructure
Network, Storages, CDNs, Clouds. Don’t forget to draw a basic infrastructure scheme. You really need to make this whole thing understandable to your partners . Always make sure they really understand.
Licenses
This part should reveal If you depend on third party modules or packages. You need to list them and also to specify license types and probably even license versions.
People
For big teams you should list the key team members only. Don’t post CVs. Mention their history, but only the history relevant to the current project. What are their responsibilities and participation on a project? What important skills do they have? Don’t forget to mention hard and soft skills.
Processes
Are you on-boarding data? What process are you using for it? What about analytics data processes? Or the most important, development and CI/CD process. There are many tools out there for UML diagrams — just use them.
Security
How do you handle the user data? Is your data protected during transfers? What security protocols are you using during transfers? If you are using third party services, where are you storing credentials? For services with the login — are you using 2FA? Do you have a central user management? How are you delivering rights? Answer these important questions.
Tech Dept
During the development there is always part of code or service that can be improved. It’s not a shame. It’s proof that you know what is missing in your code.
Testing
Be honest about how you test your client applications or services. What processes do you use? Do you test your product on real devices or emulators? You should mention how you test every component.
Conclusion
Indeed, don’t forget to be honest. Reality and real status is important. Investors are usually asking, what is the weakest part of your system? Just name that part. There is no project without weaknesses, even in Google.
