Most technical due diligence is theatre. Lawyers verify IP assignments. Accountants check capitalization. Someone asks if the code is "in good shape." Then the buyer signs and discovers the actual technical reality six months in. We have run technical due diligence on partner ventures and on our own venture builds. The framework below is what catches the things that documents do not show.
Key Takeaway
Stop evaluating technology. Start evaluating the system that produces technology. A codebase is a snapshot. The team, processes, and practices that created it determine whether that snapshot improves or rots. Four pillars — Architecture, Code Quality, Infrastructure & Security, Team & Process — and ten conversational questions reveal more than any document review.
The Problem
Buyers discover technical problems after closing because traditional due diligence treats technology as a checklist. The checklist is composed of yes/no questions a defensive seller can answer with prepared responses. The truth is in the second question — the follow-up that is harder to script. Most due diligence stops at question one.
We learned this running technical evaluations on partner ventures we considered building atop. The deals we walked away from looked clean on paper. The conversations revealed what the documents could not.
The Framework
01 — Architecture: Can the System Handle Success?
What we look for:
- Horizontal scaling proven, not promised
- Clear data architecture with documented schemas
- Graceful degradation rather than cascading failures
- Dependencies that are managed, versioned, and security-scanned
Why it matters: "We will scale when we need to" is not a plan. It is a deferral. Systems that have already absorbed a 10× traffic event have evidence; systems that have not are speculation. The same applies to failure handling: a database server with no failover is a coin flip dressed as infrastructure.
02 — Code Quality: Is the System Improvable?
What we look for:
- Test coverage on critical paths, with the team able to point to which tests catch which regressions
- Deployment frequency in the healthy range (multiple per week, not quarterly)
- Lead time from commit to production measured and trending
- Change-failure rate tracked and used to inform process changes
Why it matters: The DORA metrics survive contact with reality because they are observable. A team that deploys multiple times a week without incidents has evidence of velocity and reliability. A team that deploys once a quarter has accumulated technical debt the next deployment will reveal.
03 — Infrastructure and Security: Does the System Survive Reality?
What we look for:
- Encryption at rest and in transit
- Backup restoration tested within the last 90 days, not "available"
- Principle of least privilege enforced on production access
- Penetration testing within the last 12 months
Why it matters: Backups that have never been restored are not backups; they are claims. The first time a backup gets tested under pressure is the worst possible time. The same applies to access lists — if you cannot get the production-database-access roster within five minutes, no one is auditing it.
04 — Team and Process: Can the System Survive Departure?
What we look for:
- Bus factor above one on every critical system
- On-call rotations that work without burning out the same person
- Runbooks that exist, are current, and are referenced during incidents
- New-engineer ramp time measured in two-to-four weeks, not months
Why it matters: A strong team can fix weak code; a weak team cannot maintain strong code. Documentation tells you whether the company has built shareable knowledge or hoarded tacit knowledge in two engineers'' heads. The interview question that reveals everything: walk me through your last major outage.
Implementation Checklist
- Get the dashboard the team uses to monitor production — pulled up live, not screenshotted
- Ask for a runbook walkthrough on the most recent significant incident
- Verify the bus factor on every system touching customer money
- Confirm backup restoration was tested within 90 days
- Score each pillar 1-5; interpret the aggregate against valuation, not in isolation
What This Produces
- A technical-valuation multiplier that adjusts the price for what the documents do not show
- Evidence-based confidence (or warning) about what the post-acquisition rebuild looks like
- A walk-away signal when defensive evasion replaces specific answers
Common Mistakes
- Accepting the first answer. Defensive sellers prepare the first answer. The second question is where the real information lives.
- Treating documentation as proof. Documentation describes the intended system. Production behavior describes the actual system. They are not the same.
- Discounting team risk. A clean codebase becomes a liability when the engineer who wrote most of it is leaving. The team is part of the asset; price it.
Next Steps
If you are evaluating a venture or platform for acquisition or partnership, run the four-pillar framework before negotiating price. To see how we apply this to our own venture builds, explore the venture portfolio. For deeper engagement on a specific evaluation, see the partnership options.
Arena-forged across 8 venture lines. The framework above is what we use on our own venture-build decisions before it ever reaches a partner. See Bayanihan Harvest for the proof.