Technical due diligence · for investors, acquirers and founders
→ How investors spot technical risk in a portfolio company, before it's expensive
Technical risk is the last thing to show up in the numbers and the first thing a buyer's diligence team finds. A risk you find and fix quietly is worth far more than one the buyer finds for you.
| Area | What a buyer looks for |
|---|---|
| Human contribution | Source-control history, review evidence and modification records on material code |
| Licenses | Open-source code, datasets, model architecture and model weights, each with its obligations |
| AI vendor terms | Business terms and data-retention settings showing proprietary inputs weren't logged or used for training |
| Training data | Provenance for any model the company trained or fine-tuned |
| Policy and governance | A written policy on AI use in production, an inventory of AI systems, named owners, and evidence of human oversight |
This is a technical checklist, not legal advice. Ownership and licensing questions belong with your counsel.
I ran a full diligence packet on my own AI-built product: architecture, security, database, code quality, known limitations, and IP and licenses, with the methodology behind every number. It's the same kind of packet I'd produce for your portfolio company. → The receipts
(Pilot for Trades: R&D build · never released · no customers — by design. Architected to SOC 2 controls — built to the controls, not audited.)
I've been on the inside of companies that went through acquisitions: Advertising.com, Videology and Levels Beyond were all later acquired. I've integrated engineering teams after deals, taken SaaS platforms through SOC 2 Type II, and built in regulated industries. I know what diligence finds because I've had to answer it. → About Tom
An independent assessment of a company's technology, engineering team, security and delivery practices before an investment or acquisition. It identifies risks and estimates what fixing them will cost.
AI tools read the whole codebase, its history and its documentation in days, not a sample. A senior CTO then makes the judgment calls and writes the findings. You get more coverage, faster, with a human accountable for every conclusion.
The same way, plus the AI-specific questions: is there evidence of human review and contribution, are all licenses known (including models and datasets), were AI tools used on terms that protect proprietary code, and does anyone own AI standards? Undocumented AI use is the risk, not AI use itself.
Ownership isn't automatic. It generally depends on sufficient human contribution, which is why buyers now ask for review and development records. Treat that as a technical readiness item, and get legal advice from counsel.
Start 3–12 months out. Size your risks in writing, fix the deal-blockers (key-person risk, security gaps, unreviewed AI code), assemble the AI documentation buyers ask for, and prepare a crisp technical story.
It depends on scope and target size. A focused review can run in about a week. A full pre-investment or acquisition diligence takes longer. Scope is fixed in writing before we start.
By Tom Lang on October 5, 2026
You don't need to read code to spot a portfolio company headed for an expensive technical problem. The signals are all outside the codebase — and by the time they show up in the numbers, the problem is already costly. Here's how to read technical risk early, including the AI risk most people aren't reading yet — without commissioning a full audit.
Read more
By Tom Lang on November 2, 2026
Buyers have started asking a question most engineering teams can't answer yet: who actually owns your AI-written code? Ownership isn't automatic, and diligence now asks for records of human review, a license inventory that includes model weights, your AI tools' data-retention terms, and governance evidence. Here's the five-part checklist to have ready before the data room opens — and why it's cheap to prepare now and brutal to reconstruct later.
Read more
By Tom Lang on September 16, 2026
When I run a Diagnostic, I'm not hunting for bad code — code can be refactored. I'm hunting for systemic organizational rot: the behaviors and structural flaws that quietly paralyze a business. Here's my actual priority list of the red flags I scan for first, the tell for each and what it predicts — plus the single most dangerous flag, and the one founders brag about that terrifies me most.
Read more
By Tom Lang on September 16, 2026
The instinct after an acquisition is to immediately merge databases and consolidate cloud providers to show cost savings. That instinct destroys value. Mergers don't fail on incompatible tech stacks — they fail on mass attrition and severed context. Here's how I actually run an engineering integration: what I secure on day zero, what I integrate versus deliberately leave separate, the 90-day sequence, the cultural landmines that sink most deals, and the scar that taught me the one rule I never break.
Read more
By Tom Lang on October 5, 2026
Engineering rarely fails loudly. There's usually no single disaster — just a slow leak that looks like 'busy' right up until it looks like a crisis. Here are five signs, in business terms, that your engineering is costing you more than it should — and what each one actually signals. None of them are really code problems; they're judgment problems.
Read more