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).
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?
"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.
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?
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!
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).
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.
* 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?