Technical Due Diligence for Acquirers
TL;DR
Most technical due diligence misses the risks that actually matter — the ones that live in the code, the deployment topology, and the on-call rotation. We find them because we have shipped production software, and because we have been the target of acquisition diligence ourselves.
The Problem
You are about to spend millions — or tens of millions — acquiring a company. The financials look solid. The product demo was impressive. The market thesis checks out. But you do not know what is actually inside the codebase. You do not know whether the architecture will survive your scale. You do not know whether the engineering team can function without the founder who built the first commit.
The standard diligence report — the one produced by a generalist consultancy — will tell you that the target uses "industry-standard technology" and has "adequate security controls." It will not tell you that the auth system has no token rotation, the database has no migration strategy, the CI pipeline takes four hours, and the two engineers who understand the payment module both have competing offers.
Those are the findings that turn a successful acquisition into a write-down. They are also the findings that only an engineering team can surface — because they require reading code, tracing architecture, and talking to engineers as peers, not as interview subjects.
Why This Is Hard
Codebases do not come with warning labels. The architectural decisions that will limit your growth were not documented as decisions — they were made incrementally, under deadline pressure, by engineers who have since left. Finding them requires forensic skill: tracing data flows through multiple services, identifying coupling points that look harmless at current scale, and recognizing when a design pattern is a deliberate choice versus an accident of history.
Security assessments are particularly treacherous. A penetration test finds vulnerabilities that exist today. It does not find the systemic gaps — no secrets rotation, no dependency scanning, no incident response plan — that guarantee vulnerabilities tomorrow. You need an assessment that evaluates the security posture, not just the security surface.
And then there is the team. A codebase can be repaired; a broken engineering culture cannot. Assessing team health — bus factor, knowledge distribution, engineering practices, cultural alignment with your organization — requires conversations that go deeper than a standard reference check. It requires engineers talking to engineers, about engineering.
How Mihok Fieldwork Approaches It
We read the source. We do not delegate code review to a tool or a checklist. We clone the repositories, trace the critical paths, and assess the codebase the way we would assess our own — line by line where it matters, structurally where the risk is architectural. We identify the modules that are well-factored and the ones that will need a rewrite within eighteen months.
We evaluate infrastructure as a system, not a list. A deployment topology, an observability stack, a CI/CD pipeline, a secrets management strategy — each is individually simple to describe. The diligence value is in understanding how they interact: whether the alerting covers the failure modes the architecture creates, whether the deployment process is fast enough to support the incident response SLOs, whether the access-control model survives the acquisition.
We interview the engineers who built the system — not as subjects of a questionnaire, but as peers we might one day work alongside. We ask the questions that get past the prepared answers: What is the part of the system you are least proud of? What would you rewrite if you had six months and no feature pressure? Who else on the team could do your job if you left tomorrow?
We have been on both sides of this table. We have built systems that were acquired. We know what diligence looks like from the target side — what questions are asked, what answers are prepared, what gets conveniently omitted. That experience makes us harder to fool.
The person who scopes the problem is the person who writes the code and stays until it’s running. No junior bench. No handoffs.
Proof
Our team has first-hand acquisition experience: we were the first engineering hires at companies that were successfully acquired. We built the systems that passed diligence — and we saw, from the inside, what the acquirer\'s engineering team actually cared about versus what their procurement checklist asked for. That gap is where acquisition risk lives.
We have assessed targets across sectors — fintech infrastructure, healthcare platforms, developer tools, AI/ML startups — for acquirers ranging from growth-stage companies making their first acquisition to established platforms absorbing a competitor\'s technology. In every engagement, we have surfaced risks that the standard diligence process would have missed:
- An auth system with no token revocation — discovered by tracing the session lifecycle through three microservices, not by reading the architecture doc
- A database migration strategy that worked at 10k rows but would take the system offline at 10M — discovered by running the migrations against a production-sized dataset
- A key-person dependency where one engineer held all institutional knowledge of the payments module — discovered in a 45-minute technical interview, not a 10-question survey
- An AI model whose "proprietary training data" turned out to be a lightly-filtered public dataset — discovered by comparing data distributions against known public corpora
What is technical due diligence?
It is an engineering-led assessment of a target company's software assets, infrastructure, security posture, and team capability. The goal is to identify risks that will cost you money after close — architecture debt that limits scalability, security gaps that create liability, team dependencies that create key-person risk, and build-versus-buy decisions that were never made consciously.
How is this different from what a Big Four firm does?
A Big Four due diligence report is written by people who have never shipped production software. They check boxes against frameworks and produce a document that satisfies the investment committee but misses the risks that actually matter — the ones that live in the code, the deployment topology, and the on-call rotation. We read the source. We trace the architecture. We talk to the engineers who built it.
What does the assessment cover?
Architecture and scalability limits. Codebase quality, test coverage, and technical debt. Infrastructure, deployment pipelines, and observability. Security posture — auth, secrets management, dependency hygiene, threat surface. Team structure, key-person dependencies, and engineering culture. IP and open-source licensing compliance. We deliver a prioritized risk register with remediation costs, not a pass/fail opinion.
How long does a typical engagement take?
Two to four weeks, depending on the size of the target and the depth of access. We work fast because we have done this before — both as the acquirer evaluating a target and as the target being evaluated. We know which questions to ask first and which rabbit holes are worth going down.
What access do you need from the target?
Source code repositories. Architecture documentation (or at least diagrams). Infrastructure inventory and deployment topology. Incident history and postmortems. Access to interview key engineers — the ones who built the thing, not just the CTO. We sign whatever NDA and compliance paperwork you need.
Can you assess AI/ML systems?
Yes. We evaluate model training pipelines, data provenance and quality, inference infrastructure, MLOps maturity, and the gap between the demo and production. We look for the usual ML failure modes — data leakage, evaluation overfitting, silent model drift — and we assess whether the AI capability is a real moat or a thin wrapper around an API call.
What if the target uses a stack we don't know well?
That is exactly when you need us. Our team has shipped production systems across a wide surface — web, mobile, data infrastructure, blockchain, embedded — in languages ranging from Rust and Go to Python and TypeScript. If a stack is new to us, we have the engineering judgment to assess it quickly because we understand the principles underneath the syntax.
Do you assess the engineering team, not just the code?
Absolutely. Code tells you what was built. The team tells you whether it can be maintained, extended, and integrated. We assess key-person risk, bus-factor exposure, engineering culture, and whether the team will survive an acquisition without the founders. Some of the most expensive post-close problems are not in the repository — they walk out the door.
What deliverables do we get?
A written report with a prioritized risk register — each risk rated by severity and estimated remediation cost. An executive summary for the investment committee. A technical appendix with architecture diagrams, dependency maps, and code-quality metrics. And a two-hour readout session where you can ask us anything, in depth, with the engineers who did the assessment in the room.
Who actually does the work?
The person who scopes the problem is the person who writes the code and stays until it's running. No junior bench. No handoffs.
We are acquiring a company. Can you help after close?
Yes. Our Post-Acquisition Integration service picks up where due diligence leaves off. The same team that assessed the target can lead the technical integration — architecture reconciliation, data migration, identity consolidation, and platform unification. No re-onboarding. No lost context.
How do we get started?
Contact us with a brief description of the acquisition — target size, sector, deal timeline, and what keeps you up at night about the technology. We will respond within two business days to discuss scope, access requirements, and timing.
'/%3e%3c/svg%3e)