Technical due diligence is where rubber meets road in startup investing and M&A. It's where impressive demos get reality-checked, where hidden problems surface, and where deals get made or broken. I've been on both sides, running diligence as an evaluator and preparing companies to be evaluated. Here's how it actually works.
If You're Running the Evaluation
As the evaluator, your job is to understand whether the technology can do what the company claims and whether the team can execute on their roadmap. You're looking for three things: risks, capabilities, and honest assessment from the team.
Before You Start
Understand the business context. Technical due diligence without business context is useless. What's the company's value proposition? What are the competitive dynamics? What needs to be true technically for the business to succeed?
Define your evaluation criteria. Not every issue is equally important. A startup selling to SMBs has different technical requirements than one selling to enterprises. Security matters more in healthcare than in gaming. Know what matters for this specific company.
Request materials in advance. Architecture diagrams, system documentation, engineering team org chart, incident history, deployment frequency, test coverage metrics. Having this before you start lets you use live time efficiently.
The Technical Deep Dive
Schedule sessions with the technical leadership and with hands-on engineers separately. Leaders give you the narrative; ICs give you reality.
Architecture review. Walk through the system architecture. How do components interact? Where does data flow? What are the scaling bottlenecks? Look for architectural decisions that will be expensive to change. A microservices architecture for a three-person team or a monolith serving millions of users are both potential concerns. Watch for the common red flags that signal deeper problems.
Code quality assessment. You don't need to review every file. Sample key areas: the oldest code (does it show age?), the newest code (is quality improving?), the most critical paths (are they well-tested?). Look for consistency, readability, and appropriate test coverage.
Infrastructure and operations. How do they deploy? How do they monitor? What happens when things break? Ask to see their incident history and postmortems. A team that doesn't do postmortems or doesn't learn from incidents is a red flag.
Security posture. This varies by industry and stage, but basics matter everywhere. How do they handle authentication? Where do secrets live? What's their vulnerability management process? Have they had a security audit?
Team assessment. Talk to engineers without their managers in the room. Ask what they're proud of, what frustrates them, what they'd change. The answers reveal culture, priorities, and hidden problems.
What You're Really Evaluating
Technical debt exists in every company. Issues exist in every codebase. The question isn't whether problems exist; it's whether leadership understands them, has realistic plans to address them, and can execute on those plans.
A CTO who knows their architecture has scaling problems and has a migration plan is less risky than one who insists everything is fine while you're looking at obvious issues. Honesty and self-awareness matter as much as current technical state.
If You're Being Evaluated
Preparation matters enormously. Companies that go into technical due diligence prepared have better outcomes than those who wing it, even when their underlying technology is similar.
Before Diligence Starts
Know your weaknesses. Before anyone asks, identify your technical debt, your architectural risks, your team gaps. It's much better to present these proactively with context and remediation plans than to have evaluators discover them.
Prepare documentation. Architecture diagrams, system documentation, deployment runbooks, incident postmortems. If you don't have these, create them. The process of creating them often reveals issues you should address anyway.
Brief your team. Engineers will be interviewed. Make sure they understand the process, know what's confidential, and feel comfortable being honest. Coaching them to hide problems backfires; evaluators can tell when people are being evasive.
During the Process
Be honest. Evaluators will find problems. When they do, acknowledging them and explaining your approach is better than denying or minimizing. "Yes, we have significant technical debt in that area. Here's why it accumulated and here's our plan to address it" is a much better answer than "I don't think it's that bad."
Provide context. Raw metrics without context are easy to misinterpret. If your test coverage is 40%, explain why: maybe you're moving fast and testing critical paths, or maybe you inherited a legacy codebase and are incrementally improving. Context turns potential concerns into demonstrations of judgment.
Show your thinking. Technical decisions involve trade-offs. Walk evaluators through how you made key decisions: what you considered, what you chose, and why. This demonstrates technical leadership more than just showing the result.
Common Mistakes
Hiding problems. Evaluators doing their job will find issues. Attempting to hide them destroys trust. Even if you get through diligence, problems discovered later create serious credibility damage.
Over-selling. Describing your technology in terms that don't match reality invites scrutiny. If you say you have a sophisticated ML system and it turns out to be a rules engine, that raises questions about what else is being overstated.
Being unprepared. Not being able to answer basic questions about your own systems makes you look uninformed. Even if the answers aren't great, knowing them demonstrates competence.
What Good Due Diligence Produces
Good technical due diligence results in a report that covers the current state of technology and team, specific risks identified with severity assessments, questions that require follow-up or clarification, and recommendations about the deal.
The recommendation isn't usually "proceed" or "don't proceed" in binary terms. It's more nuanced: proceed with these risks understood, proceed with specific conditions (like key hires or milestone commitments), or don't proceed because specific issues are too severe.
Technical findings should inform deal terms. Significant technical debt might warrant a lower valuation or an escrow arrangement. Specific team risks might require retention packages. Infrastructure investments might need to be factored into funding plans.
The Meta-Lesson
Technical due diligence is ultimately about reducing uncertainty. No evaluation eliminates all risk, but a good evaluation helps everyone understand what they're agreeing to. The best outcomes happen when both sides approach the process as collaborative truth-finding rather than adversarial investigation.
If you're being evaluated, prepare thoroughly and be honest. If you're evaluating, look for judgment and self-awareness as much as current technical state. And regardless of which side you're on, remember that the goal isn't to avoid all risk; it's to understand it well enough to make informed decisions.
Frequently Asked Questions
Need help running or preparing for technical due diligence?
Let's Talk →