Making intelligent tradeoffs in software due diligence
Engineers tend to see the world in terms of tradeoffs. Certainly, successful product or solution design requires a clear understanding of the problem to be solved and the associated constraints, and then making informed tradeoffs to solve the problem within the constraints. Tradeoff thinking also applies to successful software due diligence.
The purposes of due diligence are to confirm pre-diligence understanding, gather information, and identify any unknown “gotchas” before closing an M&A transaction. All the information-gathering is in support of integration planning and can inform the terms of the deal to minimize risk in the transaction. The main constraints on due diligence are generally time and budget. (If you have an infinite amount of both, you can stop reading.) Another resource to be mindful of is the target’s time and tolerance for this “second job” of responding to myriad due diligence requests. The constraints mean that no due diligence will ever be 100% complete or perfect, but the effort can still be optimized if informed by intelligent tradeoffs.
Prioritize what matters most given the investment scenario. If the applications are public-facing, you might be more concerned about security vulnerabilities. If the new feature roadmap is ambitious or the intent is to dramatically scale a SaaS platform, energy should go into ensuring that the architecture will support future plans. If the seller stumbles when you ask about open source in the code, that should be a focus. On the other hand, in areas where the target seems to have its act together, you can take some comfort. Let’s say it seems security savvy as evidenced by a recent, reputable third-party penetration test; you might assume it is up to market snuff in that regard and not put as much energy into evaluating application security.
Additionally, your plans will determine how much you need to dig into the development team’s processes. It’s much more important to scrutinize how a team does what it does, if it will continue operate as-is. On the other hand, if the plan is to integrate the technology and merge into an existing engineer organization, then shortcomings in the current modes of operation matter less. (It’s still important to plan to remediate the issues in the code, but past process ills should be a lesser concern.) The size and maturity of the target can enter into the calculus as well. Early stage investments are bets on future software development more than past, so an emphasis on the organization and processes is appropriate. Smaller investments generally mean smaller due diligence budgets and involve less code, so that works out. On the other hand, a big acquirer needs to be mindful that integrating even a small acquisition may lead to different types of risk exposure.