Technical due diligence is not just a checkbox in the investment process. Technology can have a significant impact on an investment thesis and target valuation. For example, if the technology is incapable of scaling without significant software architecture rework, an additional investment may be required post-close.
Getting your technical due diligence team involved early in the process is paramount to fleshing out issues early. Just like software development, a show-stopper technology issue found late is more expensive and impactful to fix (e.g. increasing costs but discovered too late to affect the bid). By asking a few key questions early in the investment process, you save time, cost, and current and future headaches by validating key assumptions.
But let’s assume that you, as an investor, are not also a technologist. What questions should you ask to discover risk at the beginning of the relationship with the target company? Here are some suggestions that you can even ask pre-LOI, with rationale as to why each question is important. The answers will help direct you to areas that need deeper investigation by a trusted technical due diligence team.
Product
- Provide a brief overview of product portfolio.
- Let’s start easy – you likely already asked this question and have the target’s list of products. However, it is important to get a full inventory of products to ensure there aren’t any older limited revenue-generating products that the team is spending significant effort on maintaining, perhaps because of poorly structured contracts.
- What is the revenue breakdown and approximate level of effort (%) across products?
- Revenue should correlate to the level of effort. If a small revenue generating product is causing significant maintenance effort for the team, additional probing into the reason is required as it may hinder efficient growth.
- What is R&D spend as a percentage of revenue?
- Although acceptable answers depend on the stage of the company (e.g. mature or cash flow vs. growth), a percentage > 15% warrants investigation.
- (For each product) what are the key value proposition, markets, user personas, and use cases?
- This question provides substantial context for understanding the product portfolio, the end user, and how the product is used. It’s also a chance for an investor to understand the differences between these products and others in the portfolio (if applicable).
- How tightly are the products in the portfolio integrated together?
- A superior competitive portfolio of products is integrated together at some level. For example, single-sign-on (SSO) across products prevents a user from having multiple login credentials and logging in multiple times every time they cross products. Something like SSO makes the portfolio feel as if it is one product. If substantial work is required to integrate tightly (e.g. share the same data), then the roadmap may be affected, which could affect investment growth.
Technology
- Upon what technology platform and languages are the products built?
- Some answers may light up red flags immediately. For example, if a product is built on an obsolete and unsupported technology platform/framework (e.g. Visual Basic 6) but is a primary revenue generator, the cost to address must be factored into the valuation. As another example, if the underlying technology is known for security issues (e.g. PHP 5.x), a more urgent deeper dive on security is necessary.
- What is the fundamental software architecture (e.g. SaaS vs. on-premise, API-based, etc.)?
- Keep this high-level to start. Knowing whether the products are web-based, hosted, single-instance multi-tenant Software-as-a-Service (SaaS), installed on-premise, or some variant can inform the investment model and prepare for post-close initiatives (like a cloud migration). Keep in mind that everyone’s definition of SaaS is subtly different.
- Are all users on the same version of the software?
- Ideally, the answer is “yes”, which is the preferred model for a SaaS product. However, many versions in the wild can indicate several areas needing a deeper dive – poor support policies, difficulty of migration/upgrade, lack of customer desire to upgrade, and the team spending too much time maintaining older versions.
- How does the software architecture, infrastructure, and team scale, and have you validated?
- Scale is important to most investment theses. Although the details are not important initially, the team should have a scale story and should have validated the scale with load/capacity tests. Look for the team to describe how they horizontally scale (e.g. add server instances), vertically scale (e.g. add additional processing power; inferior to horizontal scale, however), and auto-scale (scale up or down automatically depending on load).
- What are the top 1-3 technical debt items for each of the products (e.g. legacy tech to replace)?
- A full list of technical debt is not required this early, but exploring the top 1-3 items can shed light on any major issues in the architecture that require deeper dive or may be costly to address.
- What types of data are stored within the systems?
- It is important to get a crisp understanding of what data is stored and how it is protected. A security breach can significantly impact a company’s reputation, legal footprint, and customer base. If data is sensitive (e.g. a US social security number, or a credit card number), mark this area as one significant for a deep dive. Ask for any audit/compliance reports to be placed in the data room for review.
- Have there been any major outages or security breaches in the past 1-3 years, and how were they addressed?
- A follow-up to the data security question above. Frequent outages may point to quality or security issues, and any breaches and associated responses can show how the company threats security.
- How much open source software (OSS) is in use across the products?
- A significant OSS footprint increases the probability of using components with unfriendly, reciprocal licenses. Use of a copy-left license such as Affero Gnu Public License (AGPL) can force the release of the target’s source code to the public domain and must be addressed urgently. Additionally, use of significant amounts of OSS can open up security vulnerabilities. Use this answer to decide if an OSS scan is necessary pre-close.
- Does the product suite expose a public API? Where are they documented?
- If the investment thesis revolves around using the target as a central point for future acquisitions, exposing an API enables easier and more robust integration. Documentation should be readily available in this case. Lack of an API may force reprioritization of roadmap items and increase post-close development costs to fill the gap.
Team
- What is the basic structure of the R&D team? Is all development on-shore?
- Flesh out the team structure to see if there are problematic issues. For example, a fully outsourced product may cause issues with IP and leave the target unprotected if the relationship sours. Too many distributed development centers can affect product quality and efficiency of development.
Of course, the questions and answers early in technical due diligence can be kept high-level with just enough details to expose important areas for investigation. Don’t hesitate to include your technical due diligence partner (like Cyligent!) in the conversations to help interpret the answers. Early involvement is always better than late.