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.

Author: Corinne Kutz Source: Unsplash.com

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.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store