You usually do not meet a system at its cleanest moment.
You meet it during an acquisition, a rushed migration, a funding round, or a handoff from a team that has already moved on. The repo exists. The cloud bill exists. The deployment process exists. The question is whether any of it can survive the next stage of the business.
That is where technical due diligence comes in.
Technical due diligence is a structured review of a company’s software, infrastructure, security posture, development process, and technical debt before a major business decision. For developers, it is less about the deal itself and more about one practical question:
Can this system be maintained, scaled, secured, and integrated without burning the next team out?
Start with the architecture
The first thing to check is whether the system has an architecture you can explain without tribal knowledge.
A useful review looks at:
- service boundaries
- data flow
- API ownership
- third-party dependencies
- deployment environments
- scalability limits
- known bottlenecks
If the only architecture diagram lives in someone’s head, that is already a risk.
Good architecture documentation does not need to be beautiful. It needs to answer simple questions fast. What talks to what? Where does data enter? Where does it leave? What breaks if one service goes down?
Look at the codebase like an incoming team would
Code quality is not about style preferences. It is about how expensive the next change will be.
During a technical due diligence review, inspect whether the codebase has consistent naming, readable module boundaries, automated tests, linting, static analysis, and enough documentation for a new developer to become useful without weeks of archaeology.
A few useful checks:
- Can you run the project locally from the README?
- Are major business rules covered by tests?
- Do pull requests go through review?
- Are deprecated libraries still in production paths?
- Does one person own critical parts of the system?
That last one matters. A system can look stable until you discover that release knowledge depends on one developer who is leaving after the deal closes.
Audit CI/CD before you trust deployment claims
Deployment maturity says a lot about engineering maturity.
Check whether the team has separate dev, staging, and production environments. Look for automated builds, test gates, rollback options, deployment logs, and alerting around failed pipelines.
A pipeline that exists but fails silently is worse than no pipeline in some cases. It gives everyone confidence they have not earned yet.
For cloud-native systems, also review infrastructure as code. If production was manually assembled through a cloud console over several years, migration planning becomes much harder.
Treat security as an engineering issue
Security review should go beyond a checklist.
Yes, you need to check authentication, authorization, encryption, password policies, dependency scanning, incident response, and compliance requirements such as GDPR, PCI DSS, HIPAA, or SOC 2 where relevant.
But developers should also ask how security work enters the normal delivery flow.
Are vulnerabilities tracked like engineering tickets? Are secrets stored outside the repo? Are service accounts rotated? Are failed login attempts logged and monitored? Can someone prove which user accessed sensitive data?
If the answer is buried across Slack threads and old tickets, plan for remediation.
Estimate modernization cost, not just technical debt
Technical debt becomes useful to the business only when someone estimates the cost of fixing it.
A review should separate annoying debt from deal-impacting debt. An old framework version may be tolerable for six months. A database design that blocks customer growth may change the acquisition price.
The same applies to cloud costs. Look for overprovisioned compute, unused storage, inefficient data transfer, and workloads that could be automated. Small waste compounds quickly after scale.
What should come out of the audit?
A useful technical due diligence report should give the buyer or leadership team a scored view of risk, plus practical recommendations.
At minimum, it should cover:
- architecture and scalability
- code quality and maintainability
- security and compliance
- DevOps and CI/CD
- infrastructure cost
- integration readiness
- technical debt remediation
The output should help the next team decide what to fix first, what can wait, and what might change the deal.
MEV’s full technical due diligence guide goes deeper into the process, cost range, red flags, and checklist items:
https://mev.com/blog/technology-due-diligence-how-to-do-it
Top comments (0)