The Five Pillars of Technical Assessment
When you are dropped into a data room or given access to the GitHub organization, you need a structured framework. Experienced diligence teams evaluate five interconnected pillars:
1. People & Knowledge Distribution (The "Bus Factor")
The "bus factor" is the number of people who could be hit by a bus before the project becomes unmaintainable. A bus factor of 1 means a single person holds critical knowledge that exists nowhere else — in their head, not in documentation, not in code comments, not in runbooks.
- Review git commit history:
git shortlog -sn --allreveals who actually writes the code. If 80% of commits come from one person, that's a risk. - Check documentation quality. Not just "does it exist?" but "could a new engineer onboard using only this documentation?"
- Look at the org chart. How many engineers are on work authorizations that might complicate post-acquisition retention? (Many key engineers leave after their retention cliff — typically 12-24 months post-close — taking irreplaceable domain knowledge with them.)
- Risk: If the "Hero Engineer" quits after the acquisition, the $50M asset may become unmaintainable. You've purchased a system no one fully understands.
2. Intellectual Property (IP) & Licensing
This is where engineering diligence intersects with legal diligence. You need to verify that the company actually owns the code they claim to own, and that their use of open-source software doesn't create legal exposure.
- Scan dependency manifests:
package.json,go.mod,requirements.txt,pom.xml,Gemfile. - Use automated tools like
license-checker(npm),pip-licenses(Python), or commercial tools like FOSSA or Snyk to generate a full Software Bill of Materials (SBOM) with license types. - Permissive licenses (MIT, Apache 2.0, BSD) — generally safe for proprietary use. You can use, modify, and distribute without exposing your own source code.
- Copyleft licenses (GPL, AGPL, LGPL) — these are "viral." If GPL-licensed code is linked into a proprietary application, the GPL may require you to release the entire application's source code under GPL. AGPL extends this to software accessed over a network (SaaS). This is a deal-killer in many acquisitions.
- Also check: Did contractors sign IP assignment agreements? Was any code written by employees before they joined (and thus potentially owned by a previous employer)?
3. Infrastructure & Scalability
- Request the last 12 months of cloud bills (AWS Cost Explorer exports, GCP billing reports, etc.).
- Calculate the COGS (Cost of Goods Sold) ratio: if infrastructure costs are 80% of revenue, the business model may be fundamentally broken — or the code is so inefficient that scaling to 10x users would require 10x infrastructure spend (linear scaling instead of sublinear).
- Check for infrastructure-as-code (Terraform, CloudFormation, Pulumi). If infrastructure was provisioned manually via console clicks, it's fragile, undocumented, and unreproducible.
- Look for single-region deployments, lack of auto-scaling, and absence of disaster recovery plans.
4. Security Posture
- Has the company ever had a penetration test (pen test)? Request the report and — critically — the remediation status. A pen test report with 40 open findings is worse than no pen test at all.
- Check for secrets management: are API keys and database passwords stored in a secrets manager (HashiCorp Vault, AWS Secrets Manager), environment variables, or hardcoded in source code? Run
git log --all -p | grep -iE "password|secret|api_key"on the repository to check history — secrets committed and later deleted are still in the git history. - Review authentication and authorization: are they using industry-standard protocols (OAuth 2.0, OIDC) or a homegrown auth system?
- Check compliance certifications: SOC 2, HIPAA, PCI-DSS, GDPR — depending on the industry, missing certifications can mean months of remediation work post-acquisition.
5. Software Development Lifecycle (SDLC) Maturity
- Do they have CI/CD pipelines? A mature pipeline runs linting, unit tests, integration tests, security scanning, and deploys automatically. A pipeline that just runs
npm buildand pushes to production is a risk. - What's the deployment frequency? Companies deploying multiple times per day have fundamentally different (usually better) engineering cultures than those deploying once a quarter.
- How do they handle incidents? Is there an on-call rotation? Do they write post-mortems? Is there a runbook for common failures?
A common interview question is: "You're evaluating a company for acquisition. What's the first thing you look at?" Strong answers don't start with code quality. They start with people and knowledge distribution — because code can be refactored, but if the people who understand the system leave, you can't even begin to refactor safely. Follow up by mentioning IP/licensing as the second priority because it's a binary deal-killer that no amount of engineering effort can retroactively fix.
Key Point: The five pillars are interdependent. A company with excellent code but terrible security posture is a liability. A company with great infrastructure but a bus factor of 1 is fragile. TDD requires evaluating the system holistically, not just checking boxes on individual pillars. A finding in one pillar often reveals risks in others — a bus factor of 1 usually correlates with poor documentation, which correlates with poor SDLC maturity.