How we run an AI technology due diligence, part 1: people, process, product
By Hashim Mazhar
This is the first article in a series. It gives the overview, and each of the next three articles goes deep into one pillar.
Most deal teams now see "AI-powered" somewhere in a target's deck. The demo usually works. The harder question is what the business looks like after closing: whether the teams can come together, whether the way they build holds up, and whether the technology is right for the job.
We run every technology due diligence across three pillars: people, process and product. This article covers what we look at in each, at a high level. Over the coming weeks we'll publish a deep dive on each pillar.
People: can the teams come together?
We start with strategic direction. Where does the target's team want to take the product after the deal, and how does that fit the acquirer's plans? Then we assess how much effort it will take for the teams to integrate.
We map current capabilities against gaps, and how the integration can help close them. We also look at the operating model today: whether it will change after the acquisition, and how it will adapt to the target operating model.
Questions we ask here: Where does the team see the product in two years? Which skills does each side bring that the other lacks? Who makes technical decisions today, and will that change?
Process: how does the team actually build?
We look at how the tech team designs, develops, builds and deploys.
Smaller teams tend to be more agile. Larger teams, in our experience, often still work around processes designed before AI-native workflows, such as fixed two-week sprints. We assess what that means for the team's velocity today, and whether and how the target can adapt.
We also look for practices in the current process that could expose the acquirer to compliance or reputational risk. These are often invisible in a pitch deck and expensive after closing.
Questions we ask here: How long does it take to get a change from idea to production? Where do AI tools sit in the workflow today? Which parts of how you build would you be uncomfortable explaining to a regulator or a customer?
Product: is the technology sound, and is it the right technology?
Here we cover the code base: quality, architecture, obsolescence, scalability and security.
We also assess whether each tool and technology is worth what it costs and fits what it's used for. AI is not a hammer for every nail. In a recent transaction involving a voice agent company, we assessed whether each piece of the technology was fit for purpose. Not every engineering problem needs AI, and a product that uses it everywhere can carry cost and risk it doesn't need.
Questions we ask here: Why AI for this component rather than conventional software? What does each AI component cost to run per customer? What breaks if a model provider changes its model or its prices?
What the deal team gets
A preliminary read within five days and a full assessment in two to three weeks, covering all three pillars. The deal team knows what it's buying, and what it will take to integrate, before it signs.
I led the technology side of an M&A playbook behind 16 acquisitions at a SaaS company. The lesson I took from it: the problems that cost the most after closing were usually visible before it, if someone knew where to look.
Coming next in this series
People: assessing strategic direction, integration effort and the target operating model.
Process: how AI-native ways of working change team velocity, and the practices that create risk for an acquirer.
Product: code, architecture and security, and how to tell when AI is the wrong tool for the job.
Follow Dutch Technology Frontiers on LinkedIn so you don't miss them.
Have a deal in exclusivity with an AI component? Book a 30-minute scoping call and we'll tell you what the diligence needs to cover.
