Technical Due Diligence: What to Look For

Technical due diligence is basically asking "what am I really getting?" before you commit money, time, or your reputation to a software system. I've done dozens of these assessments for clients considering acquisitions, investors evaluating startups, and companies inheriting systems from departed vendors.

Here's what actually matters and what you can safely ignore.

Code Quality: Looking Under the Hood

Code quality matters because poor code is expensive to maintain and extend. But "quality" isn't just about elegance. It's about whether the code can be safely modified by people who didn't write it.

What to examine:

Structure and organization. Is the codebase logically organized? Can a new developer find things? Spaghetti code where everything depends on everything else is a red flag.

Documentation. Not just comments in the code, but architectural documentation. Why were major decisions made? What are the known limitations? Companies that document well are usually run well.

Test coverage. Tests aren't just about catching bugs. They're documentation of how the system is supposed to work. Low test coverage means changes are risky and expensive.

Technical debt. Every codebase has some. The questions are how much, and whether the team acknowledges and manages it. Look for TODO comments, deprecated dependencies, and known issues that never get fixed.

Dependencies. How many third-party libraries does the system use? Are they actively maintained? Are there security vulnerabilities? Outdated dependencies create upgrade headaches and security risks.

Red flags:

• No tests or very low test coverage
• Single-letter variable names throughout
• Huge files with thousands of lines
• Copy-pasted code everywhere
• Dependencies that haven't been updated in years
• No version control history (yes, this happens)

Architecture: Can It Scale?

Architecture determines what the system can and can't do. Changing architecture after the fact is extremely expensive.

Key questions:

Is it appropriate for current scale? A system serving 1000 users has different needs than one serving a million. Over-engineering is wasteful, but under-engineering creates a ceiling.

What are the bottlenecks? Every system has them. Knowing where they are tells you what growth will require.

How is data stored and accessed? Database design is hard to change later. Poor data modeling creates problems that ripple through everything.

What happens when things fail? Good systems handle failures gracefully. Bad systems cascade failures into outages. Ask about disaster recovery and business continuity.

Is it maintainable? Clever architectures that only the original author understands are liabilities. Boring, well-documented architectures are assets.

Security: Where Are the Risks?

Security issues can be existential. A data breach damages reputation, triggers legal liability, and can kill a company.

Essential checks:

Authentication and authorization. How do users prove who they are? How does the system control who can do what? Weak auth is the most common serious vulnerability.

Data protection. Is sensitive data encrypted at rest and in transit? Are there proper access controls? How long is data retained?

Vulnerability management. When was the last security scan? What did it find? How quickly are vulnerabilities patched?

Compliance. If the system handles personal data, financial data, or health data, what regulations apply? Is the system compliant? Can you prove it?

Incident history. Has there been a breach? How was it handled? What changed afterward?

Common security red flags:

• Plain text passwords (still happens)
• No logging or audit trails
• Admin interfaces exposed to the internet
• Dependencies with known vulnerabilities
• No security reviews or penetration testing

Infrastructure: What Keeps It Running

Software needs infrastructure. Understanding the infrastructure tells you about operational costs and reliability.

Areas to examine:

Hosting environment. Cloud? On-premise? Which providers? How portable is the system if you need to move?

Deployment process. How does code get to production? Automated pipelines are good. Manual processes are risky and slow.

Monitoring and alerting. How do you know when something's wrong? Good operations teams have dashboards, logs, and alerts. Bad ones find out about problems from users.

Backup and recovery. Are backups being taken? Have they been tested? How long does recovery take?

Cost structure. What does it cost to run the system? How does cost scale with usage? Are there any surprises waiting?

Team and Knowledge: Who Knows What

Software is created and maintained by people. The team situation matters as much as the technology.

Questions to ask:

Who built this? Are they still around? If the original developers left, how much knowledge walked out the door?

Who maintains it now? Do they understand how it works? Or are they just keeping it alive through trial and error?

What's documented? If everyone quit tomorrow, could someone else take over? Documentation is knowledge insurance.

Are there bus factor risks? If one specific person is the only one who understands critical parts, that's a serious risk. What's the plan if they leave?

Running a Due Diligence Process

Here's how I approach technical due diligence:

1. Define your concerns. What decisions does this inform? What risks are you most worried about? This focuses the assessment on what matters.

2. Request documentation. Ask for architecture diagrams, runbooks, deployment procedures, and recent incident reports. What they can provide (or can't) tells you a lot.

3. Get code access. You can't assess what you can't see. Review should include meaningful sampling, not just a quick glance.

4. Interview the team. Technical people will tell you things that aren't in documentation. Ask about pain points, what they'd do differently, and what keeps them up at night.

5. Run automated analysis. Static analysis tools, security scanners, and dependency checkers catch issues quickly. They're not sufficient alone, but they're efficient.

6. Document findings. Categorize issues by severity and effort to fix. Be clear about what's a deal-breaker, what's concerning, and what's just normal technical debt.

What Due Diligence Costs

A basic technical due diligence review for a small system might take 20-40 hours. A thorough assessment of a complex system can take hundreds of hours.

It's worth it. The cost of due diligence is a tiny fraction of the cost of acquiring a system with hidden problems. I've seen acquisitions that looked great on the surface but required millions in remediation because nobody looked carefully at the technology.

Don't skip this step.