Buy-Side Due Technical Diligence Observations

Over the summer of 2024 I led my 20th or thereabouts buy side technical due diligence effort (Adalo) and am now at the point in which can confidently share some observations that sellers should keep in mind to maximize their chances of getting a timely deal done. So here goes.

Use a password manager

It is a major red flag if your company is not using a password manager, and is almost always indicative of uglier security discoveries that lie ahead. In fact admitting to not using a corporate password manager is such an egregious offense that I may very well try recommend torpedoing the deal because I know everything thst comes afterwards is going to be messy. If your company does not use a password manager then you objectively have a track record of playing fast and loose with both company and customer data due to careless storage and sharing of credentials. Full stop.

Further, you will logically need to share at least some and eventually all credentials with the buyer and this is going to be far easier and more secure to do via a shared vault.

Create updated architectural diagrams

I find buy side technical DD to be most effectively done by approaching the project as if onboarding like a new member of the technical team. In short I want to know how the sausage is made and that’s pretty hard to do under typically tight turnaround schedules. Updated and reasonably accurate architectural diagrams give the buyer an opportunity to see your IT environment from the 30,000 foot level, and drill down from there in a manner much more efficient than just starting from scratch and saying “tell me everything you know”.

Understand this isn’t a witch hunt

Every software developer I have ever known (including yours truly) has made regrettable technical decisions. Doubly so if made in the heat of buukding a startup. Naturally interviews with the tech team are typical during DD and you should expect to be asked all manner of probing questions about how the software and infrastructure works. A lot of those questions will begin with “Why does such and such work this way?” interviewees will often misinterpret that to mean “Why did you make the stupid decision to set it up this way?” at which point awkward defensiveness ensues. Meanwhile all the buy side team is trying to do is thoroughly document your system in order to accurately assess acquisition risk.

Never forget that saying “I don’t know” (as long as you mean it) is a perfectly acceptable answer!

I don’t believe you

Continuing with the previous theme, don’t take this personally but I don’t believe your recollection of why a technical decision was made 3 years ago. And that’s fine too, because what I really want to know is what steps are being actively taken to mitigate the poor decisions. What secret switch are you flipping every other Thursday to keep a server running? What button hidden under your desk is pushed to make sure that Mary receives her BI report every Monday morning?

Even if you answer my question with the confidence of Napoleon riding into Waterloo, tomorrow I’m probably going to ask you or one of your colleagues the same question again just to see if the story changes.