Community Comment: Part 43 - M&A technical due diligence starting point

• Initial technical due diligence guidance offered to fellow acquisition entrepreneur
• Caveat: I don't suggest software heavy business acquisitions for non-technical buyers
• As a starting point, it's important to get code access, and understand integrations and hosting / environments
• When quickly evolving third-party products like AI are involved, be sure to consider likely future costs relative to revenue

The content of this post actually wasn't posted within a community discussion thread like all of the others thus far in this series of posts, but was written by me (October 2, 2025) as some initial advice to a fellow acquisition entrepreneur.

His letter of intent (LOI) to acquire a multimillion-dollar business had been signed, and he was looking for guidance with respect to what type of due diligence should be performed. Because proprietary software was at the core of the business, I strongly suggested that technical due diligence be included alongside financial due diligence etc. As he didn't have a technical background like me, he asked me for advice with respect to what he should be looking to do as part of technical due diligence, even though I stated that I wouldn't suggest a software heavy business for anyone without a technical background.

Because everyone is under non-disclosure agreements (NDAs) during M&A (mergers & acquisitions) proceedings, no specifics about the actual business were shared with me apart from some generalities such as business domain, but to mitigate risk I won't even publicly disclose information such as this, which wouldn't really add value to what I'm communicating here anyway.

From his responses to my questions during our phone call, he shared a few details that partially drove my follow-up advice: (1) unknown tech stack, (2) integrated with at least 4 third-party software products, including AI products, and (3) possibly hosted on AWS. While these details are very high level (e.g. very general) for someone like me, these were enough to provide the following guidance with respect to what he should request as a starting point for technical due diligence: in other words, a starting point from which to ask more detailed questions:

• Access to the software code. The business should be using a version control product (e.g. Git or GitHub) that can be accessed to not only see the code you would be getting with the business, but the changes that have been made over time (e.g. in your case versions 0.x, 1.x, 2.0).
  
• While access to the code should technically give you everything you need to review the code you'll be getting with a business purchase, you mentioned that the software is integrated with at least 4 third-party products, so you should also request diagrams that help you visualize how all the pieces fit together.
  
• The diagrams provided to you should speak not just to the custom software that was written and the third-party products, but where the code is being hosted. For example, you mentioned that the code might be hosted on AWS, in which case you should know which AWS products are being used to host the code as well as which AWS products with which the code integrates.
  
• Another key request is to get an understanding of the environments being used. For example, there should be a minimum of one test environment and one production environment. The production environment is what customers use to access the software, and any pre-production environments would be used to test the software before making it available to customers.

In addition, I emphasized the following closing advice:

• I would use these as a starting point. The next steps would be to review the code and the choices that were made while the code was being written. It can be costly to maintain software, and AI products are evolving very quickly (as well as coming and going), so you'll want to get a feeling for expected future costs relative to how much revenue the software might help generate.

As an acquisition entrepreneur myself, I've gone through several rounds of technical due diligence evaluating potential business acquisitions. Combined with my decades-long background building software products, I've also been involved in several M&A related projects for mid-market and Fortune 100 firms, so I have a lot of experience that I plan to share over time in upcoming posts, and perhaps, as part of the consultation services I plan to offer.