When investors are considering acquiring a company, they often say, “We bet on the founders.” This sentiment becomes a rationale for skipping technical due diligence — an in-depth assessment of the target company’s technology strategy, assets, systems, security, and processes to identify potential risks, weaknesses, and opportunities.

Instead, their approach is rooted in faith in the leadership’s track record, implying that a strong team guarantees a well-built, secure, and scalable product—a seemingly logical approach. While this perspective was perhaps reasonable ten years ago, the dynamic shifts in technology and cyber-security and the technical sophistication of all the stakeholders involved in deals today highlight the need for a more disciplined approach to technical due diligence.

What’s Changed?

The technological landscape is no longer what it was ten years ago; it’s changing at an unprecedented pace, supercharged by near-daily advancements in areas like artificial intelligence. These changes aren’t just technical—they reshape entire industries, altering the stakes for investors and companies alike. This heightened pace of innovation demands a deeper understanding of a company’s technical infrastructure and leadership, not just to assess its current state but to identify opportunities for the company to uniquely position itself in the market through technology.

Moreover, cybersecurity has transformed from a niche concern into a central element of investment decisions. What used to be important only in sectors dealing with payments, healthcare, or sensitive personal information (PHI/PII) is now crucial across all industries. Technically sophisticated investors increasingly prioritize security measures to safeguard their investments, often making cyber insurance a prerequisite – something that is impossible if the company doesn’t at least have the basic security measures in place. This highlights the need for intelligent and comprehensive identification and addressing of all technology risks at the start of any deal.

Uncovering Critical Issues

Another common excuse, particularly in M&A, is the belief that “we will figure it out” after the deal closes. However, without rigorous tech diligence, there’s a risk of overlooking critical issues that could significantly impact the success of the deal and can lead to significant financial losses or even failure to scale as expected post-close. While some may attempt to save costs by skipping this step or relying on internal technical resources, proper tech diligence requires objectivity, expertise, and experience. Through hundreds of projects, we’ve identified core architectural issues and lax security measures that can pose substantial risks and outsize costs to the business, even in companies with strong leadership. We know what issues to look for, where to find them, and how to analyze and clarify them for all stakeholders involved.

The Overlooked Benefit: Technical Roadmap

Tech diligence should be viewed as more than just a checkbox item. This thinking misses out on one of the major benefits of tech diligence—creating a technical roadmap to success post-close. This process facilitates “forced introspection,” allowing the business to get an objective assessment of its technical strengths and weaknesses. This almost certainly wouldn’t happen without the forcing function of an imminent potential transaction.

Often, we uncover hidden and unexpected opportunities for improvement that can enhance scalability and security for investors. Moreover, the specific recommendations from tech diligence provide a framework for holding the technology team accountable and driving meaningful progress. These are invaluable resources for stakeholders and are best identified during the technical due diligence phase.

Keys for Conducting a Successful Technical Due Diligence

Several factors impact the effectiveness of technical due diligence that are commonly left to chance.

Areas to include

While each deal is different, multiple areas within the target company’s product development and technology functions should be considered for inclusion in the project. Not all of these will be appropriate for every deal, depending on the company’s stage, product offerings involved, and any previously completed diligence efforts. However, each should be considered and only excluded when there is a clear reason to do so.

• Product – Is the Product complete? Is the roadmap well-defined, and does the go-to-market strategy make sense? What does the competitive landscape look like?l
• Architecture—Is the application built securely? Is it maintainable? Is it scalable? Will a major additional investment be required in the near future to enable it to support the planned sales goals?
• Deployment—Is the hosting environment (e.g., AWS, Azure, etc.…) both secure and scalable? Are there opportunities to significantly reduce hosting costs?
• Team – Can the current team support the business in achieving the projected growth? Are there key missing roles, and can the leader lead the team to the next level?
• Process – Are there solid product development and support processes in place that will facilitate growth and a consistently high level of quality in the application?
• IT—Is the business’s IT infrastructure adequate for its current state, and where it needs to scale? Are employees able to work effectively, and is business continuity properly considered?
• Security—Does the business have solid security policies and practices in place? Do they have the proper compliance (e.g., HIPAA, SOC2, HITRUST, etc..…) for their industry?

When to Perform It

Technical Due Diligence is typically performed toward the end of the overall diligence effort. This is understandable, given the many other reasons a deal might not work out and the desire not to spend the money or effort here until there is reasonable certainty that the deal will go through. However, a few things can be done earlier in the overall diligence process to help ensure more effective technical due diligence.

First, set the expectation that access to the source code will be required if a software application (either SaaS or tech-enabled service) is to be assessed. It is common for the leadership of the target company to either have concerns about sharing access to source code or try to avoid it because of concerns about what might be found. When these concerns come out towards the end of diligence when technical due diligence begins, there is seldom the appetite for the acquirer/investor to push for it in fear of derailing or slowing down a deal at this late stage. The result is less thorough tech diligence and an increased chance of serious issues hidden in the code that won’t be discovered. Setting the expectation early that source code access will be required will help to avoid this late-stage reluctance to push for it.

Secondly, the expectation of who will be required to participate should be set. Frequently, when technical due diligence starts, it is discovered that the technical resources needed are unaware of the transaction and cannot be included, resulting in a less-than-optimal assessment. In some cases, this will be unavoidable; however, setting expectations early in the diligence process that technical participation will be needed can give the business a chance to consider including the necessary people.

Finally, a good amount of information needs to be collected before technical due diligence to facilitate the process (see our Technical Due Diligence Checklist). While it doesn’t make sense to have the technical team start on that too early for the reasons mentioned above, beginning the process a week or two ahead of the start of technical due diligence is helpful. This gives the target company time to gather the necessary information, allowing the diligence team to hit the ground running!

Execution of the Process

Multiple steps should be understood and followed with each deal to ensure a proper technical due diligence effort. They are as follows:

1. Investor Kickoff – The technical due diligence partner must have a solid understanding of the business you are looking to invest in and your goals for the company after closing. The technical requirements and skill sets needed for a business to grow 10x and launch multiple complementary products are very different from those of a company where the product is very mature, and there is no need to do major things with it. The scope of the project is also discussed here so the diligence provider knows what areas to focus on and any special considerations to take into account, such as specific concerns to look into or areas that may not require as much focus as others,
2. Information Collection – Gathering any information the company has documented related to the roadmap, process, team structure, architecture standards, security policies, etc… is very helpful in getting a full picture of where things stand ahead of direct meetings with the team. Getting this information to the diligence team up front goes a long way towards reducing the time required for the product development team to meet with the diligence team. (See the link above for a comprehensive checklist of questions and material to request.)
3. Company Kickoff – A kickoff call among the Investors, Tech Due Diligence team, and key Product/Technical leaders in the target company is crucial in getting everyone aligned on the technical due diligence process and their roles and addressing any team questions. As part of this meeting, the tech diligence provider will establish key contact points for the various workstreams, get key follow-up meetings lined up, and provide an overview of the process.
4. Function-Specific and Individual Meetings – Following the Company Kickoff, several “function-specific” meetings (e.g., Product, Architecture, Team, Process, Security, etc.…) are typically scheduled. In some instances, when deeper insights are needed around the team and leadership, multiple individual contributor meetings will likely be held.
5. Assessment – Equipped with all the information provided and notes captured from the meetings above, the team can now dig in to do their actual assessment. This includes reviewing documents, reviewing notes, digging into the source code, looking through the team’s project management tools, inspecting their cloud hosting environments, etc….
6. Report Compilation – The technical due diligence team will write up their findings and recommendations in a report using the insights gained above. This must include both the technical detail the team will need to remediate issues found but also a clear and easy-to-understand “snapshot” for the investor outlining where things stand, what issues they need to pay attention to, and whether there is an excessive risk to the deal based on the findings.
7. Stakeholder Review – The technical due diligence team will walk the investors and other stakeholders through the report, outlining the important things the investor needs to know, why they are important, and what the company needs to do to rectify each issue.
8. Action Plan Review With The Company – A technical due diligence effort and resulting findings should not just be used as a go/no go decision point for investment. For most deals, many other issues are identified that don’t raise up to the level of interest for what the investor is looking for. Having the provider walk the company through the findings leverages the effort spent on technical due diligence to help update the company’s technical roadmap. This process can highlight valuable recommendations that may not have previously been on their radar.

Selecting the Right Technical Due Diligence Partner

The final step to ensure a successful Technical Due Diligence project is to select the right partner – there are several considerations here:

Using an individual versus a firm specializing in technical due diligence – while it is common to use an individual who is either part of the firm or a friend of the firm (possibly a CTO from another portfolio company), this approach is limiting. Looking across the scope of what should be covered (see above), one person can’t have the requisite expertise across all those areas to be fully effective. Furthermore, effective technical due diligence is just as much an art as a science, requiring emotional and business skills that go beyond the capabilities of many technical professionals. Using resources not experienced in tech diligence will limit the value obtained in the effort.

Capacity and Bandwidth—It is important to work with a provider who can take projects on quickly, complete them quickly, and have expert resources across all the areas mentioned above, including multiple architect resources with expertise across a wide variety of common tech stacks.

Clear and Actionable Report—Spotting technical issues is not the hard part of tech diligence. The best providers stand out by having the discernment to understand which issues are important to the deal and being able to present those clearly and concisely to non-technical stakeholders. Ask to see examples of previous reports.

Ongoing Support—While it is good to be aware of the key technical issues identified in diligence, it is common for the company not to have the expertise or bandwidth to remediate those issues. Work with a partner who can provide expert, ongoing fractional support (CPO, CTO, and/or CISO) and be available to jump in to help clean things up after the close.

Conclusion

In today’s tech-driven landscape, technology due diligence is indispensable in any investment or acquisition scenario. Betting solely on founders or assuming any technical issues can be figured out post-close is no longer viable. With stakeholders’ increasing technical sophistication, informed decision-making pre-close and strategic planning post-close are imperative. Embracing tech diligence is not just about mitigating risks but maximizing the potential for long-term success.

For more information on TechCXO’s technical due diligence services, visit https://www.techcxo.com/technical-due-diligence/ or contact me at greg.smith@techcxo.com.

FAQs

Q: What is technical due diligence?

A: Technical Due Diligence is the evaluation of the technical aspects of a business, typically within the context of an acquisition or an investment. These technical aspects include product viability, application architecture, cloud infrastructure, product and technology teams and processes, IT infrastructure, and security posture. Outside experts in the areas outlined perform an audit to compare the target company’s people, process, and technology against industry best practices, seeking to identify any risks stakeholders need to be aware of before proceeding with a transaction.

Q: What are the benefits of technical due diligence?

A: The benefits of technical due diligence include visibility into a company’s technical risks that can negatively impact scalability and/or require significant unplanned additional investment to remedy. In addition, proper technical due diligence will leave the target company with a technical roadmap outlining the items that must be addressed to ensure scalability and continued customer retention.

Q: How much does due diligence cost?

A: The cost of technical due diligence can vary very widely depending on the scope of the assessment, the size of the target company, and the number and size of the applications the company has developed. As a high-level guideline, below are estimates for the various stages of investment:

Seed: $10k – $15k

Early: $20k – $35k

Growth: $40k – $55k

Mezzanine: $60k – $80k+

Q: How long does technical due diligence take?

A: The duration of a technical due diligence project depends on several factors, including the scope of the assessment, the size of the target company, the responsiveness of the company, and the number and size of the applications the company has developed. As a general guideline, below are the typical durations for the various stages of investment:

Seed: 2-3 weeks

Early: 2-3 weeks

Growth: 3-4 weeks

Mezzanine: 4-6+ weeks

Q: Is technical due diligence required?

A: As the pace of technical advancements increases and business reliance on technology increases, ensuring that a business’s technical capabilities are in good shape is required. It is critical to understand any inherent technology risks and to get a clear picture of any significant unplanned costs that would only come to light when the business tries to scale. Additionally, unlike five years ago, cybersecurity is now a significant consideration in technical due diligence for all types of businesses, not just product development companies. Skipping technical due diligence significantly increases the risk profile of potential investments.

Q: Can I use a technical person I know (perhaps a CTO from one of our portfolio companies) to perform technical due diligence?

A: You can; however, there are several reasons this will limit the value that you receive from the technical due diligence. First of all, the breadth of the technology landscape is expansive (and growing) – to think one person can adequately cover the different aspects of tech diligence and the multitude of tech stacks is unrealistic. Secondly, quality technical due diligence is something that only some technical people can do well since there is just as much art to it as science. Finally, an individual will not likely have a structured report that contains not just the technical details but also the discernment from an investment perspective of what the investor needs to pay attention to. For a more in-depth discussion on this topic, see the article ‘Why ‘We’ve Got a Guy’ Falls Short in Today’s Complex Technical Due Diligence.’

Q: Why can’t we just “bet on the leadership team”?

A: Some firms don’t perform technical due diligence as they are betting on the leadership team. The logic is that if the leadership team is strong and there is a product with happy customers, then any technical issues that come to light later can be figured out. The problem with this logic is that it is very common for companies to have an application in the field that is working well from a customer’s perspective but will not scale, requiring significant additional investment down the road. Similarly, there could be a tech leader in place who presents well, but when you dig in, is really not the right person to take the team to the next level. Having an objective and expert assessment removes the gaps that are left when you just “bet on the leadership team.”