Technical due diligence is an essential component of the M&A lifecycle for most businesses today. But what exactly are private equity firms, investment banks and acquiring companies looking for when it comes to technology? Our technical due diligence checklist highlights what’s most important.
The importance of technical due diligence
Would you buy a new home without having it inspected by a seasoned professional? Most people wouldn’t. The cost of a home inspection is negligible compared to the home’s value. It can provide significant peace of mind or even modification of the sales price to accommodate any defects or needed maintenance. Why not just do the inspection yourself? For starters, most people do not have the expertise to inspect the fine details themselves.
Additionally, every construction is different, so inspection is a bit of an art — you have to have a good eye and the wisdom to know what to look for. Previous experience building houses is helpful or even mandatory. Most people cannot be experts in all aspects of home construction, including structure, plumbing, electrical, general maintenance, and overall quality and aesthetics. With all these variables at play, hiring an outside third-party to help evaluate and protect your investment intuitively makes sense.
The same concepts hold true when investing in a software company. Private equity deal partners, and even leaders at acquiring technology companies, are typically well-versed in financial concepts, but may not be technology gurus. Using a third party to help evaluate the technical aspects of the target software company is akin to using a professional home inspector.
Most acquiring firms have a set of investment objectives in mind when acquiring a new technology company. Performing technical due diligence to evaluate the product, architecture, processes and organization ensures that those objectives are met prior to closing the investment. Additionally, a detailed look at these aspects helps validate any assumptions the investment firm has made, such as the ability to scale the number of users 10x in three years.
So why not just do a basic technical due diligence yourself, particularly if you are a software company acquiring another software company? First, competitive intelligence may be at stake, and a third party with a signed non-disclosure agreement can help preserve that integrity. Second, using a third party with team members of varying expertise, an objective view and the ability to compare hundreds of companies to the target adds further value to the diligence process.
How a technical due diligence checklist helps the process
A refined technical due diligence process is quick, efficient and answers the investment questions in easy-to-understand terms with sufficient detail. Target companies are typically analyzed from three perspectives:
- Technical risks to the investment, coupled with the cost to mitigate
- Opportunities for growth post-close to help meet investment objectives
- Strengths of the company that should be preserved and/or built upon moving forward
Sample technical due diligence questions and analysis
Analyze each of these perspectives from the following categories. Included below are some sample questions to ask and answer:
Product strategy and product portfolio
- Does the product strategy fit with the investment company’s growth objectives?
- What are the product strengths, weaknesses, opportunities, and threats (SWOT) to help validate a reasonable direction is possible?
- How does the company determine the product roadmap, and what will add the most business value?
Product function and quality
- Are there obvious quality problems with the product, such as performance issues, that may be expensive to fix?
- Does the product fulfill end-user goals in a practical way, or is an expensive UI revamp necessary?
Architecture and code
- Is there anything in the architecture that impedes meeting growth objectives?
- Are there legacy components in the software that require replacement? How much will this replacement cost?
- Are there third-party or open-source components that may be problematic from the legal or technical view?
- Is the code written in a maintainable way so that others can quickly be productive in the code base?
Processes, practices and tools
- Are there opportunities for efficiency gains and/or cost reduction?
- Will the existing practices scale appropriately with company growth?
- Are there existing skill gaps that inhibit efficient delivery?
People and organization
- Are the right people in the right roles to meet investment objectives (particularly leaders)?
- Who are the people critical to the business and must be retained with the acquisition?
- Are there significant gaps in the organization that you must fill to meet investment objectives?
- Is the level of R&D spend appropriate for the company size? Are there opportunities for reduction?
IT / Operations / DevOps
- Are there opportunities for cost reduction, such as a move from locally managed resources to the cloud? What is the cost of doing so?
- Is there a suitable business continuity plan in place? If not, what is the risk, and what is required to implement one?
- Are the expenditures reasonable given the company size?
- Are deployment practices efficient with minimal risk of human error?
Product support
- What are the top support call generators that may be indicative of product problems?
- How many escalations make their way to the development team?
Professional services
- Are implementation times long, potentially indicating a lack of configurability / customization in the product?
- Are there opportunities for product enhancement to scale to a larger number of customers requiring less on the services side?
Final word
While tech challenges identified during technical due diligence may not make or break a deal, it is important for investors to understand the risks and opportunities when evaluating a potential investment. When discovered in advance, technical risks may affect the ultimate deal conditions or price. But when discovered post-close, these same risks can impact scalability, delay product development, create unforeseen costs and derail the value creation strategy.
