4 ms·

Thanks! * What are the most common gotchas? * What tools do you use to do the technical due diligence? * What would you suggest to prepare for it? * What wo

by ericb 4y ago

Thanks! * What are the most common gotchas? * What tools do you use to do the technical due diligence? * What would you suggest to prepare for it? * What would acing it look like?

Closi 4y ago
I'm not OP, but when I experienced due dilligence the thing I found counter-intuitive was that 'looking really good at everything' isn't actually the best approach. As an example - it might be better that the company doing Due Dilligence finds you awful at sales during the DD phase, because they will see that you got revenue despite poor sales technique and they will see it as an easy target for improvement / 'to generate value'. Companies want to identify ways that they would be able to help the company they are aquiring. Not sure if this applies to Technical DD, but thought it was interesting enough to share!
- jacquesm 4y ago
  Yes, that's called 'hidden upside'. You can of course also disclose this before DD. As a rule, surprises during the DD process are to be avoided if you can, even positive ones (because you may lose out on a bid from a party that would have bid if they had been aware of it). source: yaddp.
  - mbesto 4y ago
    Exactly this. You don't pass or fail Tech DD...it's more to provide comfort to the buyer.
- wslh 4y ago
  OP is specifically talking about tech due diligence which is specific within due diligence in general. One thing that appear in tech due diligence is quality of the technical architecture and implementation, and security risks associated.
  - jacquesm 4y ago
    And: quality of the people... if there is one distinguishing factor it is that one. Bad tech can be fixed, and if there is a competent team that got put in charge of a pile of tech debt then there is hope.
mbesto 4y ago
* What are the most common gotchas? Surprises! We don't like surprises, and nor do our clients. From a tech perspective - dated tech, unmanageable (or no clarity of) tech debt, NIH syndrom * What tools do you use to do the technical due diligence? OSS scanning and security scans mostly * What would you suggest to prepare for it? I'l try to answer this simply, which is - read GitLabs documentation and if you have similar and more importantly - actually operate this way, then you'll be more than prepared. * What would acing it look like? As I mentioned below, there is no pass/fail. Acing it is - be honest, be prepared, and have a plan (not for the tech dd itself, but rather a plan for your business).
- biztos 4y ago
  Do you look at codebase quality? As in, have someone good at Language X go through the target's repos and deliver a verdict on how good the actual code is, and how well it's organized etc?
  - mbesto 4y ago
    More or less yes. The tooling for this is getting much better.
- ollien 4y ago
  What makes something like outdated tech a "surprise", rather than just "reality"? As in it was actively hidden from you, or just not something anyone thought worth mentioning until it came time to plow through the code?
  - mbesto 4y ago
    "Surprise" could be interpreted a few different ways. Here's an example to elaborate: - Company being acquired ("Target") built a web based application in the mid-2000's using VB.NET and each client installed the software. It requires a desktop widget to be installed at their clients locations to talk back to the VB.NET web backend. In 2016 they switched their licensing model from perpetual license to subscription and now the web application is hosted by the target and not the clients. - Target tells acquirer they have a "SaaS" application. So, now its a VB. NET web app with single tenants hosted on the Target's data centers. Not untenable, but the acquirer was probably expecting a multi-tenant SaaS web app in a more generally supported web framework. And, yes I've absolutely seen this case (or something very similar) in the wild.

by ericb 4y ago

Thanks! * What are the most common gotchas? * What tools do you use to do the technical due diligence? * What would you suggest to prepare for it? * What would acing it look like?

Closi 4y ago

I'm not OP, but when I experienced due dilligence the thing I found counter-intuitive was that 'looking really good at everything' isn't actually the best approach. As an example - it might be better that the company doing Due Dilligence finds you awful at sales during the DD phase, because they will see that you got revenue despite poor sales technique and they will see it as an easy target for improvement / 'to generate value'. Companies want to identify ways that they would be able to help the company they are aquiring. Not sure if this applies to Technical DD, but thought it was interesting enough to share!

jacquesm 4y ago
Yes, that's called 'hidden upside'. You can of course also disclose this before DD. As a rule, surprises during the DD process are to be avoided if you can, even positive ones (because you may lose out on a bid from a party that would have bid if they had been aware of it). source: yaddp.
- mbesto 4y ago
  Exactly this. You don't pass or fail Tech DD...it's more to provide comfort to the buyer.
wslh 4y ago
OP is specifically talking about tech due diligence which is specific within due diligence in general. One thing that appear in tech due diligence is quality of the technical architecture and implementation, and security risks associated.
- jacquesm 4y ago
  And: quality of the people... if there is one distinguishing factor it is that one. Bad tech can be fixed, and if there is a competent team that got put in charge of a pile of tech debt then there is hope.

mbesto 4y ago

* What are the most common gotchas? Surprises! We don't like surprises, and nor do our clients. From a tech perspective - dated tech, unmanageable (or no clarity of) tech debt, NIH syndrom * What tools do you use to do the technical due diligence? OSS scanning and security scans mostly * What would you suggest to prepare for it? I'l try to answer this simply, which is - read GitLabs documentation and if you have similar and more importantly - actually operate this way, then you'll be more than prepared. * What would acing it look like? As I mentioned below, there is no pass/fail. Acing it is - be honest, be prepared, and have a plan (not for the tech dd itself, but rather a plan for your business).

biztos 4y ago
Do you look at codebase quality? As in, have someone good at Language X go through the target's repos and deliver a verdict on how good the actual code is, and how well it's organized etc?
- mbesto 4y ago
  More or less yes. The tooling for this is getting much better.
ollien 4y ago
What makes something like outdated tech a "surprise", rather than just "reality"? As in it was actively hidden from you, or just not something anyone thought worth mentioning until it came time to plow through the code?
- mbesto 4y ago
  "Surprise" could be interpreted a few different ways. Here's an example to elaborate: - Company being acquired ("Target") built a web based application in the mid-2000's using VB.NET and each client installed the software. It requires a desktop widget to be installed at their clients locations to talk back to the VB.NET web backend. In 2016 they switched their licensing model from perpetual license to subscription and now the web application is hosted by the target and not the clients. - Target tells acquirer they have a "SaaS" application. So, now its a VB. NET web app with single tenants hosted on the Target's data centers. Not untenable, but the acquirer was probably expecting a multi-tenant SaaS web app in a more generally supported web framework. And, yes I've absolutely seen this case (or something very similar) in the wild.