Technical Review in a Company Acquisition

As part of the Pardot acquisition a few years ago, there was an extensive technical review during the due diligence. As you would expect, the idea was to evaluate the technical underpinnings of the product and to try and assess if it was well made and will continue to perform as the company grows. Only, a technical review by a third-party is incredibly difficult as languages, frameworks, deployment strategies, etc. are all different and nuanced.

Here are a few areas of technical review in a company acquisition:

  • Code Walkthrough – Much time was spent walking two senior engineering managers through how the code was organized and styled. Here, the goal wasn’t to evaluate every line of code, but rather to see that it was maintainable and that we were thoughtful in our approach.
  • Architecture – After the code walkthrough, the next step was to draw out the architecture of the product and explain how all the modules interfaced with each other. With a standard Model-View-Controller approach, the basics are usually straightforward.
  • Data Storage – With so much information being stored across so many different customers, data storage and retrieval was a big deal. Of particular note were the areas where data was growing the fastest as well as our strategy for keeping up with the growth.
  • Deployment – When a software engineer makes a change, what happens before customers get to see or use that change. How much human intervention is required? Is it automated? What tests have to pass? Where does the code go?
  • Hosting – With a complicated web-based application, the number of servers and services can be quite large. An acquirer wants to understand how manageable the hosting configuration is and how hosting costs grow as the customer base grows (hopefully there are some economies of scale in the hosting costs as revenue grows).

Note that nowhere during the process was there a consideration for how well our product could integrate with their product or if our product was written in the same language and/or style as their product. For acquisitions whereby the product is going to continue on as a standalone application, the goal is make sure that it’s well made and will continue to perform as the business grows. Technical reviews, in my limited experience, are much easier than expected.

What else? What are some other thoughts on technical reviews in a company acquisition?

3 thoughts on “Technical Review in a Company Acquisition

  1. We went througg not just a review but an audit by a third party and interviews of the tech talent. In the process we had feedback and were requested to make adjustments but overal it was s smooth process but this was only due to having a solid code base, documentation and testing procedures in place. Some companies are more interested in your talent than the product and in those situations the tech interviews are more important than the review and/or audit. So, ultimately, having great people and great development processes, coding and documentation can play huge dividends as not having this is a huge red flag. So, not only do you need a successful product and company but you need the discipline and talent to support the acquisition consideration.

  2. David, As usual I found your comments spot on. I would add to this an assessment of the maturity of the development processes and the level of testing depending on the criticality of the product. Bug tracking and history leading to a determination of the software reliability (how are they trending) is an assessment we insist on. Jim Grebey

  3. On a technical services company note I would add that an acquirer does still focus on software development maturity and process and how well deployment and versioning are managed even though they don’t delve into the specific architecture of any client software solutions that you are delivering other than a global inventory of languages and server platforms you deploy to in order to get a sense of your overall competency. On a related technical note though the areas they do focus heavily on is your disaster recovery process and that needs to be documented well and pass scrutiny so they know you are mature as far as backups, offsites, and recovery outside of just source control. Having an email retention policy is also very good to have buttoned up and written down going into an acquisition. Lawyers can probably help best with that since they tend to like having fewer historical emails sitting around rather than having ten years of emails hanging around.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.