What a Technical Due Diligence Engagement With Us Actually Looks Like

Technical due diligence is one of the more common requests we get through consulting, and also one of the least consistently understood. Someone is buying a company, investing in one, or inheriting a codebase through an acquisition, and they need a technical read on what they're actually taking on before the deal closes. The brief that arrives is usually short: "can you look at the codebase and tell us if it's okay." What that actually requires is more specific than that sentence suggests.

We've done enough of these now to have a real process rather than improvising each time, so this is a walkthrough of what a due diligence engagement with us actually looks like, not the marketing version, the actual sequence of what happens once we're hired.

Before we look at a single file, we want to understand what the client is actually deciding. Is this an acquisition where the buyer plans to keep the existing team and just wants to know what they're inheriting, or one where the team is leaving and someone else has to run this code from day one? Is the timeline weeks or days? Is there a specific risk someone's already worried about, a security concern, a scaling concern, a single point of failure in one engineer who's leaving? That context changes what we spend our limited time looking at more than anything in the code itself.

A due diligence engagement with an unclear scope wastes the client's time and ours, because we end up producing a generic health check instead of an answer to the actual question they're trying to make a decision on. We push back on vague briefs at this stage rather than starting work against one.

Once scope is set, we ask for repository access, deployment access if it's relevant to the question, and a short call with whoever currently knows the system best, if that person is available. We start with the commit history and the dependency list before we start reading feature code, because those two things tell us more about the codebase's actual condition, fast, than a week of reading business logic would. Commit history shows how the code actually evolved, whether there's a single author doing everything, whether tests get written alongside features or not at all, and how recently the codebase has been actively maintained versus coasting.

The dependency list tells us about risk exposure quickly: unmaintained packages, dependencies with known vulnerabilities, or a stack built on something end-of-lifed that nobody's flagged. None of that requires deep familiarity with the product's domain, which is exactly why it's a good first pass.

After the fast pass, we go looking for the actual architecture: how services talk to each other, where the data lives, what happens under load, and where the system would break first if traffic doubled overnight. We're specifically hunting for the mismatch between what the architecture looks like it's designed for and what it's actually being asked to do in production, because that gap is where most real risk hides. A system built for a thousand users that's now serving fifty thousand isn't a code quality problem, it's a scaling cliff that the client needs to know is coming.

We also look for the parts of the system nobody wants to touch, because every codebase has at least one. Those are usually found by asking the current team directly rather than by reading code, since "what part of this are you afraid to change" gets a more honest answer than any static analysis tool.

The report we deliver is organized around decisions, not around code quality in the abstract. Every finding gets tied back to a question the client actually needs answered: does this affect the price, does this affect the timeline, does this need to happen before close or can it wait until after. A finding that's technically true but doesn't change the deal doesn't make the report, because a fifty-page document full of minor style complaints buries the two or three things that actually matter.

We're also explicit about confidence level. Some findings come from reading the code directly and are near certain. Others come from limited access or short conversations and are our best read given the constraints, and we say so rather than presenting every finding with the same authority.

We've been brought in after the fact, post-acquisition, to look at a system the buyer wishes they'd had reviewed beforehand, more than once. The pattern is usually the same: the deal moved fast, the technical review got compressed into a couple of hours on a call, and the actual state of the codebase only became clear a few months in, once the new team was already responsible for it. That's a more expensive way to find out about a scaling cliff or a dependency risk than paying for a proper review upfront would have been.

This is also why we turn down engagements where the timeline genuinely doesn't allow for a real look, rather than doing a rushed version and calling it due diligence. A two-hour review presented with the same confidence as a proper one is worse than no review at all, because it creates false assurance instead of an honest gap.

If you're acquiring a company, investing based partly on its technology, or inheriting a codebase through any kind of transition, and nobody with direct technical authority is independently verifying what you're taking on, that's the gap this kind of engagement fills. It's not about finding a reason to kill the deal, most of the time it doesn't. It's about knowing what you're actually agreeing to before you agree to it.

If that's a decision in front of you right now, our contact page is the fastest way to reach us and talk through timeline and scope before anything is signed.