Architecture and technical due diligence during fund raise — Do’s and Don’ts

Whether you are looking to raise investments for your startup or finding a company for acquisition, technical due diligence is important. The process is extensive and full of details.

Over the last 1.5 years I have conducted few architecture and technical due diligence(on behalf of VC firm) on multiple startups from pre Series-A to Series-F, where investment ranges from 20M USD to 200M+ USD.

In this article I want to share some of experience and do’s and don’t for during your technical due diligence by VC firms.

What actually is technical due diligence?

First things first, Technical due diligence is the process of analyzing and evaluating the technology, product, technical architecture review and processes in a company before the acquisition or an investment. Basically, Investment firm that is investing is trying to evaluate — How much a company is actually worth?

Technical due diligence process explained —

This is an idea of what a typical process looks like but varies depending on stage or product.

1. The start — This involves introduction between the participants. The initial meetings happen with the CTO (mostly). The discussion happens at a high-level about the technical architecture, deployment, infrastructure, scalability etc.
2. Documentation — Documents are requested on architecture, process, team or any MVP(for early stage companies). Level of documents vary based on the stage of the company.
3. Meeting — Post this specific meetings will happen, say for example, meetings to have in depth discussion on architecture, infra costs, tools etc. Based on company stage and preference, either architect or team lead or CTO can lead the meeting.
4. Access — Depending on the firm and stage and you might be asked to give access to your code(this is very very rare though) or any of the internal tools(think of metrics/analytics dashboard, infra dashboard, team portals or product docs) to validate systems. Trust is an important factor and most of the time, data over excel should be enough. So, please be honest and genuine.
5. Report — the last step involves creating a report of due diligence. Based on observations, the final report is shared. Reports contain the current state of systems and suggestions or feedback by consultants.

Having understood a bit about technical due diligence, what is it that you should avoid at any cost? Let us walk through some pointers of what should and should not be done.

The Dos and Don’ts

Following are some tips on dos and don’ts

Dos:

1. Be honest (you don’t need to have perfect systems)
2. Have some documents handy, regarding architecture flow etc
3. Be extremely precise and clear on numbers. So, know your numbers before the first meeting.
4. Have clarity on roles(irrespective of company size). Please get the right person and let him lead the conversation. See, as CEO or CTO you are always tempted to pitch in and interrupt your colleague during call. This shows lack of preparation, communication and clear ownership.

Don’ts:

1. Don’t try to explain what’s not true or right. Consultants understand technology and they know how systems work.
2. Please don’t bullshit and pretend to be what you are not.
3. Don’t compare processes or tools with other companies. See, every company is unique and the investors would value what your differences are and how they bring about benefits.
4. Automation is not everything. Automation at an early stage is counterproductive to your startup growth. So, you don’t have to say there is 100% code coverage, all deployments are automated and bug free. We all understand how deployments go right?
5. Stop using fancy words like ML Algorithms and AI for simple stuff you are doing. They don’t give you any brownie points.

I hope you have a clearer and better picture of technical due diligence from what you started reading.

Apart from this, following is the checklist to be talked about like:

1. Preparation for technical architecture review/infrastructure documentation
2. Code/data quality — how to make it better
3. Organizational chart
4. Operational processes
5. Deployments / Security

One final suggestion, technical due diligence is more about conversation between company and consultant. It’s not an evaluation or an interview. Just, be open and enjoy the conversation and see for mutual learnings.

If you are company raising funds or a VC firm which needs technical evaluation on the company, and need some help, you can schedule a free call with me @

https://calendly.com/_khaleel/technical-consult-with-khaleel-30mins-free-consulting

Khaleel Pasha - Founder, asklua.ai - Free remote interviewing platform - AskLua | LinkedIn