Most technical due diligence is a consultant interviewing the CTO for three days. We analyze the software itself — every commit, every dependency, every decision trace — and hand you evidence, not a summary of what you were told. Independent of the team being assessed, and kept current as the deal moves from LOI to close.
Technical due diligence — sometimes called tech due diligence, technology due diligence, software due diligence, engineering due diligence, or a technology risk assessment — is an independent assessment of a software asset's real condition. The baseline is a code review: does the code have violations, and does it meet the compliance it should? That matters — but the code, examined by itself, can't answer the questions that actually decide a deal:
Those answers don't live in the source alone. They live in the commit history, the tickets and PRDs, and the people who made the decisions. So we audit the whole system — the code, the decisions that shaped it, and the knowledge holding it together — and you leave understanding not just what the software is, but why it became that way.
The baseline: does the code meet the standards and regulations it claims? We surface security vulnerabilities, business-logic flaws, GDPR and SOC 2 exposure, and audit-trail gaps — read directly from the code, not a questionnaire.
How far has the built system diverged from what was specified? We compare PRDs to tickets to commits to the code that shipped. The gap between stated intent and actual implementation is where surprises live.
Who owns what — and what happens when they leave? Git-history analysis finds the developers who hold unique expertise over critical subsystems. A bus factor of one on a revenue-critical module is a material risk, quantified by component.
Will it support the growth thesis? We map the real system topology, not the aspirational diagram, and identify the coupling, bottlenecks, and single points of failure that bite when you push past today's scale.
Will you have issues running it? Deployment history, failure modes, and operational debt — the difference between software that demos and software that runs reliably once it's yours.
What do you actually own? Every declared and undeclared dependency, with copyleft contamination and AGPL exposure flagged. Source is processed in isolated environments under full confidentiality.
Not all debt is equal. Change-driven prioritization surfaces the code that is both complex and frequently modified — where maintenance cost and delivery risk actually concentrate.
What would it cost to rebuild this from scratch today? We normalize total code volume to person-years and separate genuine custom IP from open-source and boilerplate.
We connect to repos, CI/CD, and infrastructure under NDA in an isolated environment. The target's team keeps shipping; nobody's workflow changes.
Our tooling reads the code and its full history — every dependency and decision trace — plus architecture and risk mapping. Read directly, not from interviews.
Consultant review, story synthesis, and an executive briefing. Deliverables formatted for an investment committee or board.
Formatted as five stories — each answering one question the deal team needs resolved — backed by the supporting evidence below.
Every engagement is led by the founding partners — not handed to a rotating junior team. The independence is structural: we lead with the read and have nothing to sell you afterward.
Serial founder and technologist. Co-founded UrbanSitter as CTO, scaled multiple engineering organizations, and holds a US patent in business intelligence systems. LinkedIn
CTO and Head of Technology across AI, edtech, and enterprise platforms — Ferret, ZYYAH, UWorld, Roger CPA Review — and founder of OpenCircle, applying machine learning to real-world decisions. LinkedIn
See exactly what the read produces in the sample technical due diligence report — or meet the team on the about page.
Our standard engagement runs three weeks, built for deal speed: read-only access and NDA in week one, automated analysis and knowledge-graph construction in week two, and consultant synthesis plus an executive briefing in week three. We operate under data-room restrictions and accelerated schedules when the deal demands it.
A traditional consultant interviews the team and reviews documentation, then writes up what they were told. We analyze the code, commit history, and dependencies directly — so the findings are reproducible evidence, not a synthesis of self-reported claims.
Five stories formatted for investment-committee consumption, plus a prioritized risk map, compliance readiness by framework, a dependency and license audit, a key-person dependency map, and strategic options with effort and trade-offs. You also keep a searchable knowledge base of the system.
No. The same analysis serves acquirers and investors during diligence, CTOs who inherited a codebase, and operators preparing a company for sale. The lens changes; the underlying evidence doesn't.
A thorough technical due diligence checklist covers eight areas: compliance and security violations, requirements drift, ownership and knowledge concentration, amenability to expansion, operational reliability, IP and open-source risk, technical debt hotspots, and cost-to-replicate. We assess every item from the code, commit history, and dependencies directly — not a questionnaire — so each line of the checklist is backed by reproducible evidence.
Yes. Private equity firms and their operating partners are a core use case — both buy-side technical risk assessment before an investment closes and portfolio-company reads after. We deliver code-level evidence an investment committee can defend: cost-to-replicate, key-person concentration, IP and open-source exposure, and a prioritized risk map, all traceable to the commit. The independence of the read is the point: it isn't the management team's narrative, and it isn't a number you have to take on faith.
No — a code review is a subset of it. A code review asks whether the code is well-written and free of violations. Technical due diligence asks whether the asset is what the deal assumes: how far it has drifted from requirements, who holds the critical knowledge, whether it scales to the growth thesis, what you actually own, and what it would cost to replicate. We do the code review as the baseline, then correlate it with commit history, tickets, and ownership to answer the questions that decide the deal — which a code review alone cannot.
Yes. Sell-side preparation runs the same read before a buyer's diligence team does, so you find — and can address or get ahead of — the issues that would otherwise surface mid-process: undisclosed open-source exposure, a bus factor of one on a revenue-critical module, or debt concentrated where it will scare an acquirer. Walking into diligence with your own defensible read is the difference between setting the narrative and reacting to someone else's.
What We Are Not
We don't write code, manage your engineering team, or sell you a transformation roadmap. Our only interest is an accurate picture — which is exactly why you can trust it. What happens next is your decision, made with the right information for the first time.
Three weeks. One investment. Complete technical clarity before you sign.
Get a Read