Technical due diligence checklist: Why acquiring firms need it

Private Equity Industry, Technical Due Diligence

Technical due diligence is a highly recommended component of the technology company investment cycle, whether you are a private equity firm, investment bank or acquiring a company. Find out why, as well as some of the mandatory areas to explore with this technical due diligence checklist.

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 value of the home and 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 possess 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, 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. In a list of 20 due diligence activities necessary before a merger or acquisition, Forbes notes technical due diligence and intellectual property review as number two. Leaders of acquiring companies like private equity (PE) firms, or even other technology companies, are 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 helps ensure 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 3 years.

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.

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-investment close to help meet objectives
  • Strengths of the company that should be preserved and/or built upon moving forward

Each of these perspectives is analyzed 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 is an impediment to 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 such that others can be productive in the code base quickly?
  • 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 skills 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 must be filled 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 in doing so?
    • Is there a suitable business continuity plan in place, and if not, what risk is undertaken, and what is required to implement one?
    • Are the expenditures reasonable given 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 lack of configurability / customization in the product?
    • Are there opportunities for product enhancement to scale to larger number of customers requiring less on the services side?

While many items found during technology due diligence may not make or break a deal, it is important to understand the risks and opportunities to evaluate a potential investment. The existence of technical risks may affect the ultimate deal conditions or price. The cost of a technical due diligence is insignificant compared to the magnitude of a software company investment, and the benefits abound, which leaves us with the question — why wouldn’t an investment firm conduct pre-acquisition technical due diligence? I certainly wouldn’t buy a new home without an inspection.

For access to a downloadable version of this technical due diligence checklist, click here.

Crosslake has conducted many pre-acquisition technical due diligence evaluations. Our senior people use a process that involves planning, a kick-off with the investors, a kick-off with the target, an information request for pre-study, an on-site visit with interviews and code walkthroughs, follow-up, and a detailed report with our findings. Most importantly, Crosslake validates the investment objectives and tailors the evaluation to the investment firm’s needs.