The exact framework we use to assess a software acquisition target in ten working days: what to ask, read, ignore, and report to the board.
Technical due diligence has a tendency to expand to fill whatever time is given to it, and a rushed one-day review misses everything that matters. Ten working days is the range we have found actually forces the right discipline, long enough to read real code and talk to real people, short enough that it fits inside a deal timeline without becoming the reason a deal slips. The structure below is the one we run for most acquisition targets in the twenty-to-two-hundred-engineer range, adjusted up or down depending on codebase size and how many products are actually in scope.
The first two days are almost entirely about getting access, not about forming opinions. Repository access, CI and deployment dashboards, infrastructure-as-code, incident history, and an organisational chart of the engineering team are the minimum starting set, and the speed at which a target can produce these tells you something in itself. We build a simple system inventory in parallel, every service, every datastore, every third-party dependency with a cost or a licence attached, because a target's own architecture diagram is reliably out of date and the inventory we build ourselves becomes the reference document for the rest of the engagement.
This is the heart of the technical review, and the goal is representative sampling, not exhaustive coverage, since exhaustive coverage of a real codebase in three days is not possible and pretending otherwise produces false confidence.
Code quality is only half the picture, and the other half lives in the team. We run structured interviews with engineering leadership and, where the target allows it, with individual senior engineers, looking specifically for key-person risk, whether critical system knowledge lives in one or two people's heads with no documentation, and for how incidents are actually handled versus how the incident process document says they should be. We also ask directly about attrition and morale, since a team that expects to leave shortly after acquisition changes the entire risk calculation for the deal, whatever the codebase looks like.
A focused security and compliance pass covers access control practices, secrets management, data handling against whatever regulatory regime applies, and any prior security incidents or audit findings the target can produce. We are not running a full penetration test in two days, that is a different, longer engagement, we are looking for structural red flags, credentials committed to source history, production access shared too broadly, customer data handled without the controls the target's own compliance claims imply.
The last stretch of the two weeks is writing, not discovery, and the discipline here matters as much as the research that fed it.
Part of running a tight two-week process is knowing what not to chase. We do not spend time on vanity engineering metrics, lines of code, commit frequency, or story point velocity, none of which correlate meaningfully with the health of a system. We also discount sunk-cost narratives from the target's own team about why a piece of architecture is the way it is, the history is interesting context but it does not change the risk the acquirer is actually taking on. The two weeks stay focused on what the code and the team demonstrably do today, and what it will cost to change what needs changing, because that is the only version of due diligence a board can actually act on. This is the same framework our IT consultancy team runs for clients evaluating a technical acquisition.
Before we start, please share a few details so we can follow up with you.
End this conversation? Your chat will be emailed to us.