Bernard Fraenkel, SVSG Practice Lead, explains the process of technical due diligence, a key step in the technology company investment cycle. Bernard has led engineering teams of all sizes for over 30 years in Silicon Valley and around the world and oversees SVSG’s due diligence engagements. This piece is the first in a series showcasing what our CTOs have learned from performing dozens of technical due diligence assessments. Stay tuned and follow SVSG on social for updates.
Purpose of Technical Due Diligence
All due diligence activities seek to uncover any facts that might materially impact the investment thesis. In technical due diligence, we want to identify any technical issue that will significantly impact the product roadmap, and thus push out in time projected sales and revenues. We also want to identify major risks, current or future, that could impact the business objectives of the company: e.g. security, development velocity, ability to attract talent, etc. Finally, we also look on the positive side for any unique and defensible intellectual property, technology, tools, processes that might have been under-appreciated by the investors, as well as opportunities to accelerate the product roadmap.
When thinking about technical due diligence, we begin with understanding the needs of our client: the investor (or acquirer). By the time we are called upon to investigate a company’s technology, market prospects have been established, competition evaluated, etc. In a technical assessment we are not asked to validate an investment decision, our objective is to appraise the likelihood that technology will hinder (or accelerate) the execution of the business plan on which the investment decision was made.
As a corollary, technical due diligence is not a beauty contest where scores are given for how well the technology works today. Rather, it strives to be a crystal ball that identifies the main technical milestones necessary to achieve the company’s business plan. We take a dynamic view over the next 24 months to determine the demands made on the technology by the growth of the company during this time period—be it scale, product roadmap, new markets/users, development velocity, product quality, security, or predictability of the organization—and then correlate the plan from the engineering team with our own assessment of the design and efforts required to meet the business plan and revenue targets.
The Main Questions Addressed During Technical Due Diligence
By their very nature, high-growth companies experience a high rate of transformation. As a consequence, everything is always changing, and nothing is right.
On the technology side, 24 months is a long time, during which it is guaranteed that major projects will take place, whether it be a re-architecture, refactoring, or the introduction of new tools/processes. If none of these have been identified, it’s almost always a red flag. Consequently, technical due diligence strives to identify these major projects, as well as validate that they have been properly designed, planned, and scoped.
In the past couple of years, as AI has become more prevalent, a majority of due diligence projects require an evaluation of the sophistication of the company’s machine learning algorithms, as well as their data pipeline (quantity, quality, frequency, …).
Here are some topics that turn up frequently:
- How must the software architecture – as well as the data center – evolve in order to meet the growth in traffic? Will a major re-architecture, or refactoring, project be required? If so, have the corresponding resources been taken into account in the product roadmap?
- Is the technology stack modern enough to sustain a competitive development velocity—and attract new talent?
- How must security be tightened up in order to meet the larger number of users, new features, new markets?
- How sophisticated are the data science and machine learning algorithms claimed by the company? Does the company have proprietary data sets and pipeline?
- Does the technical team have the right talent at all positions: development, product management, QA, DevOps, system operations, data science, AI?
- What is the quality of the code today, and how well is it organized? Will it be conducive future growth?
- How much effort will need to be invested in upgrading tools and automation—as well as processes—across the whole development value chain: development, as well as QA, DevOps, system configuration (CI/CD), system and performance monitoring and tuning?
- How many key hires will be needed in the technology team?
- How efficient are communications between the business and technology teams?
- Does the company have tangible intellectual property (IP) that differentiates it in the market, and provides a barrier to entry to competitors (potentially including well-funded ones)?
While by nature the focus of the review is to find the bad news, it is equally important to highlight the strengths of the technology and engineering team—which may not have been appreciated by financials-driven investors
Getting Started
Technical due diligence happens when the firm is mature enough to have technology worth investigating. Usually, this happens at later rounds of investment. An investor will approach us once they have signed a term sheet with a startup, requesting that the technical due diligence be performed before the deal closes – typically in 2-3 weeks time.
This means that we have to work very fast to assemble our team. Because of this short time frame and the breadth of the investigation, having a large pool of technology executives with relevant experience is critical to the ultimate quality of the evaluation.
At the start of the project, we capture the investors’ perspective on: (a) the major business milestones (e.g. capture a new market in 9 months), (b) the major product milestones (e.g. new product to be launched in 6 months to capture new market), and (c) major risks, or areas of concern that have been identified so far. This insight provides context to our exhaustive review of the company’s technology.
Because a given technical challenge can be solved in many different ways, the due diligence team must be well-versed in the technology stack of the company being reviewed, and be familiar with the market, users, and applications of the product. For example, requirements for security, or user interface, are vastly different for a social app than for a company trading financial assets.
As a consequence, the due diligence team must have a large breadth of technology expertise (software architecture, programming languages, system operations, …), technology stacks (Python, .NET, Java, node.js,, …) as well as real-life experience in companies of various sizes so that they can identify—from personal experience—the major technical milestones that the company under review must accomplish in order to reach its next stage of maturity.
In addition, the quality of the technology must be calibrated against the maturity of the company: scaling 10x does not mean the same thing when you have 10,000 enterprise users versus when you have 1,000,000 consumers. Test automation is nice-to-have when you are starting to penetrate a market, but it becomes critical when the company has grown and is about to saturate the market. The same applies to data center infrastructure, development processes, tools, and automation.
We also must be open to approaches that are different from our own beliefs about the right way to do things. After all, by nature we are dealing with some of the most creative people in the world!
The Process of Technical Due Diligence
Once we have captured the business context from the investors, as well as the areas of risk identified so far, we engage the executive team of the company under review – typically the CEO and the CTO, and perhaps the VP of Product and technical leads as well.
The three main phases of the project are:
- Information dump from CEO and CTO
- Kickoff web conference – 2 hours
- Technical deep dive web conference – 2 hours
- Code review as well as data center review performance, plus ad-hoc Q&A with technical team (this is the time intensive part)
- Preparation of the written report and presentation of findings to investors – 2-3 days
Unless specifically requested by the investors, the technical due diligence is performed remotely. The typical duration of the engagement is 2-3 calendar weeks, driven in part by the depth of the work performed by SVSG and by scheduling and availability of the company’s exec team.
Deliverables of Technical Due Diligence
SVSG takes the time to provide a comprehensive written report to our clients. Most of them find that it provides them a valuable roadmap of the major technology deliverables over the near to mid-term after the investment. It also provides an easy reference to major risks that the executive team must manage on the technology front.
The report provides:
- Executive summary: overall assessment of the strength of the technology, as well as a summary of major findings (positive and negative)
- Schematic of software, and data center, architectures (not always available from the company under review)
- Technology stack description
- Major findings by area:
- Software architecture
- Data center architecture
- Technology stack
- Code quality
- Testing strategy
- Tools and processes: product management, development, QA, DevOps, system operations
- Operational competence
- Product development methodology
- Organization, talent
- Areas of focus requested by client (e.g. scalability, machine learning, …)
- Overall assessment of the technology team (including CTO) to meet the business objectives of the company. Major milestones to accomplish in the next 24 months
- Recommendations for technology, operations tools, methodology, organization and team
Conclusion
Technical due diligence is an essential step to take for investors and acquirers to fulfill their fiduciary responsibility, and it is worth understanding on that basis alone. In a follow-up post, we will explore the art of due diligence and how we at SVSG have learned to approach it.
To Learn More