Technical Due Diligence: Make No Mistakes – Follow These 9 Key Elements
04 July 2019
Many startups dream of achieving two things – getting that crucial investment to skyrocket growth or getting acquired by one of the global giants.
However, the road to the finish line is full of obstacles and hurdles.
One of them is technical due diligence.
We’ve created this guide with the best recommendations to make this process as successful as possible for your company.
What is Technical Due Diligence?
Technical Due Diligence is a process of analyzing the technical aspects of a product or a service. It typically happens before fundraising rounds and mergers and acquisitions. These complex transactions necessitate a stringent due diligence investigation.
The due diligence process may entail one large investigation that is broad or a few separate investigations that focus on different topics. Companies that spend at least 20 hours on due diligence have better chances of getting higher and positive returns from their investments. If you are a retail business, for example, and you are on the path of building a marketplace, it may have the sense to merge with an existing online business. That’s why you need technical due diligence in this scenario.
How Does a typical Tech Due Diligence process go?
- Intro – the technical due diligence actually starts before it officially starts. A proper intro between the participants is the first step, being open, honest, and punctual helps to set the proper framework for the further steps while being evasive, permanently busy may harm the trust too early in the process.
- Kick-off call – the “official” start of a due diligence process is usually a kick-off call, where the requirements and detailed process steps are shared between the parties, and the dates are defined.
- Documentation screening – Before actually coming in person, analysts performing the due diligence usually go through all the existing documentation – architecture, processes, backup and recovery, monitoring, servers – the more you have properly documented the better.
- On-Site DD / remote call – Usually, for the growth phase investments, a live meeting in person is a mandatory requirement – investors prefer to know for sure that things really function the way they are described. It is usually a 1-2-days session when different technical parts of the service or product are analyzed “in real-time”.
- Follow up – often a lot of questions would appear during the previous steps – in this case, usually, these questions and unclarities are answered in 2-3 follow-up iterations.
- Report – as usually investors do not perform the technical due diligence themselves, and engage independent specialists, the end result of the due diligence process is a detailed report, where all the pros and cons are highlighted, and the overall judgment is disclosed, whether technically the product or service is reliable enough.
Key Elements Necessary for Passing Technical Due Diligence
Preparing yourself for a good TechDD means balancing your strong points while not shoving weak points under the carpet. There will always be some skeletons in the closet (and it is expected) so do not hide them!
Not every DD is the same. It depends on the investment stage.
In the Seed or A stage, the business focus is on building the product. So the focus of due diligence will be on the potential.
In the A / B / C stages, the business focus is on growing, and that’s when the investors are mostly interested in the product’s ability to scale and adapt quickly.
In the C / D stages, it is all about expanding and maturing. Investors are looking for an exit or an IPO and they will be most interested in maintainability and compliance.
Architecture & Infrastructure
Prior to technical due diligence, your company needs to be well prepared to present and describe your technology. Things such as documentation, architectural charts, scalability, performance indicators, etc.
The scope of documentation will depend on the business area and on the funding stage, and who is reviewing it of course.
You also need to be able to explain how your technology/product/service compares to what your competitor is offering.
When it comes to infrastructure, crucial things that need to be well explained include programming languages, app servers, databases, and all other technologies that compose your product.
Always ask yourself, what’s the current state of the infrastructure?
Investors are going to review the entire infrastructure of your system in order to avoid any troubles with the integrity and security of the project.
How To Prepare For This Factor?
In order to prepare for this first step, make sure to have all your documents archived.
These documents would include everything created over the years –
- product design documents,
- architectural descriptions,
- API documentation,
- operational metrics and more.
An interested party who is looking to acquire your company or invest in it will want to hear about open source components, but also third-party tools that are being used along with the patch tools and deployment. Be sure to always show integrations with other products in your ecosystem.
What investors, buyers, or potential partners will want to know are also past problems, failed attempts to solve them, and what you as a company are doing now to address the most important and pressing issues.
A major thing to consider is scalability.
When assessing startups, many investors want to see the data of all tests that were performed.
This is especially true for new companies that have yet to deploy their solution with larger customers and systems. Typically, investors will ask for a copy of all source code.
Be sure to provide documents on all security vulnerability scans and penetration tests that were performed in the past.
Equifax has learned this the hard way. Open source components are a popular attack vector for many hackers so you shouldn’t forget to track and report the security of these open source components in the code.
Code maintainability is another important thing. If it is not maintainable it means that it won’t be easy to modify. Other developers should be able to pick it up without too much trouble.
Automated test coverage is a technique that should be used on a regular basis. This technique determines whether test cases are covering the app code.
In simpler language, what this actually does is it gives the confidence of making changes without worrying that something will break over.
Source: Kratin Mobile
Code quality in the system is one of the most important aspects. A badly built system can cause a heavy ‘technical debt’ on an organization so it’s crucial to pay special attention to this area.
The poor code can cause various issues and higher costs of ongoing maintenance.
That’s why during the acquisition process you need to take into consideration both the financial and operational side of code quality.
Some key areas to take into consideration include:
- Code Coverage – Does the system have little or poor testing in place?
- Code Quality – If the code is sub-optimal it is going to cause long-term issues
- Documentation – Make sure to document inline commenting, notice about setup, the maintenance of services architecture, APIs provided and used, etc.
- Testing – Look for testing processes on the front-end and data repository too
- Error reporting – Have a system of logging internal errors and do ongoing monitoring
It may seem redundant at first, but every good technical due diligence checklist must include people.
People are an important part of every product. Investors want to have an organizational chart with roles and key players in the company.
A list of contractors and outsourced roles may be required from some investors as well.
How To Prepare For This Factor?
Try to always have an updated version of your organizational chart. Keep the database with resumes of all employees and contractors along with their contracts and associated costs.
You can even go a step further and create a list of people with their skills, matched with different parts of the product.
Think about the future as well. Are there roles that you wish to invest in the future? Provide a list of these as well.
A good team should have a mix of skills. Developers are mandatory but so are designers and product managers.
Consider how well these teams are interconnected. Is there good communication between team members? This is a very important but often overlooked thing when it comes to creating a successful product.
Sometimes what makes the whole difference when developing a great product is having good leadership. Most investors won’t only look at how great your product is. They are going to assess the quality of your team too.
They are going to pay a special interest if people in your company have enough leadership experience to carry the project.
Operational Processes and Workflows
This factor consists of providing information about your company’s development. Things that should also be included consist of quality assurance, security testing processes, deployment, and operations.
Think about how you can be effective and cost-efficient but also how your company can support the continued development of products.
How To Prepare For This Factor?
Again, everything comes down to one important aspect – documentation. You need to document all of your organization’s processes, people involved, costs, timetables, etc. Have a backup of all of them.
Also, create reports on the most important performance metrics and KPIs.
These would include time to version release, the time needed to fix critical bugs and security issues.
Intellectual Property & Licensing
Source: Your IP Insider
For most investors, intellectual property is one of the most important assets. Your company will need to present the patents that protect your IP.
You will need to showcase strong proof that you are not infringing on intellectual property that isn’t your own. A very important aspect is related to the third-party components that are part of the software, especially free and open-source ones.
How To Prepare For This Factor?
Keep your company’s patents updated regularly.
Make sure to track all open source components used by your team in order to prevent any legal troubles.
These include dependencies, licenses, sources. Third-party components should also be well documented.
Top-notch security is a top priority for every technical due diligence checklist. Especially for fintech apps.
The official standards for software quality are ISO25010 and ISO27001. These ISO standards are identical in content worldwide. Some countries make adjustments to the name of the standard by adding the acronym of the national quality body but this has no impact on the actual content and its requirements.
A technology roadmap supports the long-range planning of your company. One leads to another and in this case you need to demonstrate how your technology supports your product or service initiatives.
Typical elements that are being reviewed during the tech diligence process include:
Current Tech Stack
In short, a tech stack is a combination of all software products and programming languages used to create a web or mobile app.
What language or framework your team is going to use is a very important factor, especially in the early stages. It will set the course for everything else that will happen afterward.
Create a tech stack that fits you best and that will support the growth of the business as a whole.
A scalable product should be able to achieve two things – handle a large volume of users and generate enough revenue without adding massive costs.
In order to create a scalable product, you need to have a good plan.
The most important thing is reviewing certain elements of the design process, especially the number of users your product can serve at the time.
Other things to consider include:
- Operating platform – What operating platform do you use and how it scales out?
- Disaster recovery – If something unexpected happens, what plans are in place? What steps need to be taken for full system recovery?
- Diagnostic monitoring – How often do you examine the logs to improve system quality and performance?
- Data repositories – How is the data stored and managed? What are the data storage limits?
- Load testing – What methodology is used for load testing?
It’s quite rare that a system will run without occasional issues so you need to examine what structures are in place for development, maintenance, and end-user support.
Two crucial things are existing development support and end-user support.
Existing Development Support
Is there a technical induction process when new resources are brought onto the team? Also, pay attention if there are any contracts with third-party suppliers to assist the development team.
You will surely have some kind of end-user support requirement.
Reviewing user support history can help with evaluating future support requirements within your own organization. Also, heavy user support can significantly slow down an integration project.
And last but not least, investors would want to know the future plans your company has.
Will there be any new products in the upcoming period? Or are there any features that you think will be worth implementing for even bigger success of your current product.
How To Prepare For This Factor?
Document all plans for your solution. If possible, create roadmap options for future products. You should also keep a list of features that were requested by your customers.
Tips For Passing Technical Due Diligence
Do a Tech DD “Dry-Run”
“Dry-Run” is a term from the testing world, meaning performing a test as close to reality as possible, to identify the problems early and have the risk of a possible failure mitigated.
Practically, startups do engage the same consultants that investors usually call, to perform a proper Tech Due Diligence, and identify any possible issues before they start a fundraising round.
That helps them to get the “as if” feedback very early, and work on the found problems; helps companies and their CTOs to feel prepared and know what to expect.
Usually such a “dry run” is first performed 6-9 months before a major funding round is started, and another “verification” run 4-6 weeks before the actual Due Diligence.
Don’t Pretend to Be Someone You Are Not
A huge red flag during the tech diligence process is to avoid presenting yourself as someone you are not. There is no fake-it-till-you-make-it in technical due diligence.
The whole point of passing a tech due diligence process is to gain the trust of the investors and possible acquisition partners. Honesty is the best policy!
Address your skeletons in the closet proactively, or, if it isn’t possible to address this very quickly, at least share ideas on how you plan to fix them. Even more important is to do deliver on these plans, as in some cases investments would be divided into tranches, where some tranches would be tied to the resolution of some of the identified problems (e.g. unit tests, or some architectural availability or scalability problems).
Prepare for These Typical Questions
These are some typical questions that come up during a tech due diligence.
- “What parts of your tech landscape keep you awake at night?”
- “Which changes would you apply to your current architecture if you had to scale from now (transactions/requests) 2x, 10x, 100x?”
- “Can you explain the reasoning behind the choice of XY? Why didn’t you [make/buy] it?
- “Can you describe your role and responsibilities as CTO”
Add to this Technical Due Diligence Checklist for a Pass
This checklist is not totally exhaustive.
Depending on your exact business and industry, technical due diligence may look a little bit different but these should serve as the starting point. You can also work with a technical due diligence provider if you want to outsource this to someone else.