Ask HN: What technical due diligence should be performed before M&A?
7 comments
Have a look at https://jacquesmattheij.com/due-diligence-survival-guide/ . He covers more details in the second part also.
I have led technical due diligence during acquisitions as both the acquirer and the one being acquired more then once. The link you gave is interesting and definitely has some good points. Some suggestions, first, If you went through a 3rd party, e.g. investor, investment bank etc to find/acquire this company ask for their due diligence checklist. If you didn't and are on your own then I'd try and get a few different checklists from others and combine them, for example if your company is backed by a VC, ask them for a checklist or reference to get one.
A few things I didn't see on that list I always look into. There are a ton more things, too much to try and list here.
1. Licensing of components, 3rd party software etc. Abusing license terms is not unheard of in small companies or startups in general and it usually doesn't bite them until they are acquired or raise a big round. Once a vendor thinks there are deeper pockets to pick they may pursue their rights more aggressively, you just need to know.
2. Get copies of the past 12-24 months of invoices from all technology purchases. Your finance team will probably want this too, but you need it to see what they have paid for and might be using or have embedded someplace that the team has just overlooked or forgotten. The time period might differ based on age and size of the company and how often they deploy updates etc. The less the deploy updates the more you should be digging.
3. Goes with #2 but separate, get a list of all technology vendors (including consultants etc) they use (eventually you'll want their account representative information and account details). Use this list to compare to #2 and find discrepancies.
4. Have them demonstrate to you some of the processes, not just tell you and/or document them. For example, if they have prod/staging/dev environments and state they have a way to replicate anonymized data from prod to staging, make them show you, don't just assume it is there and works. Watch a deployment or two if you can, but stay out of their way and just evaluate -- I made a mistake there one time. FWIW: I was on a team that evaluated one company that had amazing documentation and things looked super solid until you actually sat and watched, and then you figured out none of the documentation lined up with the real processes and without certain employees you'd never know the truth and never be able to piece it together.
5. Get a list of employees in the technology team with job descriptions and a rating (or last review etc), e.g. how critical is this person to daily operations, critical IP knowledge, team morale. This isn't about finding people to get rid of, it is you looking for who might have key knowledge that you need to work hard to retain/recruit, or understand and get documentation etc. Also, it is about patterns if you see Joe on team A is involved with everything it might mean he is just super good and been around awhile, or it may be he blocks progress constantly and you need to know.
Technical due diligence is a balance between technology and people, and the people side is super critical. You might find the source code is awesome, product is absolutely stellar, but you find they are violating major license terms of 3rd parties that are owed significant sums of money, or have cause to sue. You may find that the critical people that really know the system already moved on to a new company and left over is the B team and that is a factor on negotiations. Obviously this is all in addition to reading the source, getting presentations on how it all works and comparing the notes etc.
A few things I didn't see on that list I always look into. There are a ton more things, too much to try and list here.
1. Licensing of components, 3rd party software etc. Abusing license terms is not unheard of in small companies or startups in general and it usually doesn't bite them until they are acquired or raise a big round. Once a vendor thinks there are deeper pockets to pick they may pursue their rights more aggressively, you just need to know.
2. Get copies of the past 12-24 months of invoices from all technology purchases. Your finance team will probably want this too, but you need it to see what they have paid for and might be using or have embedded someplace that the team has just overlooked or forgotten. The time period might differ based on age and size of the company and how often they deploy updates etc. The less the deploy updates the more you should be digging.
3. Goes with #2 but separate, get a list of all technology vendors (including consultants etc) they use (eventually you'll want their account representative information and account details). Use this list to compare to #2 and find discrepancies.
4. Have them demonstrate to you some of the processes, not just tell you and/or document them. For example, if they have prod/staging/dev environments and state they have a way to replicate anonymized data from prod to staging, make them show you, don't just assume it is there and works. Watch a deployment or two if you can, but stay out of their way and just evaluate -- I made a mistake there one time. FWIW: I was on a team that evaluated one company that had amazing documentation and things looked super solid until you actually sat and watched, and then you figured out none of the documentation lined up with the real processes and without certain employees you'd never know the truth and never be able to piece it together.
5. Get a list of employees in the technology team with job descriptions and a rating (or last review etc), e.g. how critical is this person to daily operations, critical IP knowledge, team morale. This isn't about finding people to get rid of, it is you looking for who might have key knowledge that you need to work hard to retain/recruit, or understand and get documentation etc. Also, it is about patterns if you see Joe on team A is involved with everything it might mean he is just super good and been around awhile, or it may be he blocks progress constantly and you need to know.
Technical due diligence is a balance between technology and people, and the people side is super critical. You might find the source code is awesome, product is absolutely stellar, but you find they are violating major license terms of 3rd parties that are owed significant sums of money, or have cause to sue. You may find that the critical people that really know the system already moved on to a new company and left over is the B team and that is a factor on negotiations. Obviously this is all in addition to reading the source, getting presentations on how it all works and comparing the notes etc.
wow some great info here ... thanks so much
The agency that represents me, 10X Management, offers this service.
Thanks for the reply. Would you know what this type of service typically costs. Ballpark.
https://decodingvc.gitbooks.io/p9-startup-tech-due-diligence-calculator/content/section1-assessment.html