Another consideration is the nature of the target company’s application portfolio and the plans going forward. Prioritize future money-makers over waning legacy products that you plan to end-of-life. Worry less about internally used applications than market-facing applications. You can refine this by particular risk areas as well. You might want to ensure a widely used cash cow product is secure, but if the plan is not to add significant functionality, you needn’t dig into the architecture too much. With regard to third-party licenses, recognize that there are a few problematic licenses for a SaaS back-end than for, say, distributed mobile apps.
Consider too, the depth in which you dig into all these areas. It’s not a binary decision, whether to evaluate code quality or development processes. The question is really how deep you go and how much energy goes into it. Just asking a few questions about a particular concern can provide useful information, albeit not to the depth of detailed code analysis. So a good practice is to go broad and shallow initially, ideally before due diligence even commences, and then use those up-front learnings to decide how deep to go, in which areas, and for which code.
Again, in an ideal world, software diligence would deep-dive into all risk areas of every product or software application, but practically, time, budget, and seller’s resources never allow. It’s worth noting too that time constraints can be addressed with money, by applying more internal or third-party resources while still being mindful of overwhelming the target’s capacity. A trusted third party (yes, like Synopsys) is particularly suited to code analysis, as targets are unwilling to share code with a prospective acquirer. And once such a service provider has the code, there is no additional burden on the target.