Technical diligence for the AI era.

Is the architecture coherent, scalable, and maintainable — and, in the AI era, does it reflect real engineering judgment? This is where my hands-on edge lives: I read the code the way the next engineer will have to, and assess the AI-provenance signals specifically —

• Test coverage relative to generated volume — do the tests genuinely verify behavior, or were they written to pass?
• Architectural coherence — one design mind, or many local answers stitched together?
• Dependency sprawl — what got pulled in, and who understands it now?
• Commit & review patterns — does the history show judgment, or accepted output?
• Maintainability — can the team change what the tooling produced, or only regenerate it?

• Risk rises whenthe codebase looks mature but no one can safely change it — or a fragile architecture is being scaled past its limits. Volume without understanding.

How the team plans, builds, reviews, tests, and ships. Is delivery repeatable and measured, or heroic and dependent on individuals? I look across the whole software development lifecycle: planning and estimation, branching and review discipline, CI/CD, testing strategy, and how predictably work moves from idea to production — including release and incident response.

• Risk rises whenprocess lives in people’s heads, releases are risky events, and there’s no repeatable path to production.

The team behind the code — its structure, depth, and where the knowledge actually lives. Single points of knowledge are the quiet deal-killer, but organizational risk runs broader than any one person: I assess how the org hires, develops, manages, and exits people, how it onboards and trains, whether critical knowledge is documented or lives only in people’s heads, and whether it can absorb a departure or scale with the plan. Finding organizational issues early, and naming what it takes to fix them, is the point.

• Risk rises whencritical systems depend on one or two people, the bench is thin, and the organization has no repeatable way to hire, develop, and retain the engineers it needs.

How mature the product and engineering function are relative to the company’s stage and the investment thesis. Is the organization building for where the business is going, or barely keeping up with where it is? I assess roadmap credibility, technical debt and its trajectory, scalability headroom, and whether engineering investment matches the growth the deal assumes.

• Risk rises whenmaturity lags the stage, and debt is compounding faster than it’s paid down.

I run security scans across the code and the architecture, and review the history of security incidents and how the team responded to them. I assess data handling and the system’s resilience to failure, then flag the critical, highest-severity risks in plain English — the failure modes that turn into a breach, an outage, or a liability after close.

• Risk rises whensecurity is an afterthought, sensitive data is mishandled, and single points of failure go unmanaged.

Good software has to run in production, not just pass review. I assess the operational picture: live telemetry and monitoring, error tracking and logging, on-call and incident response when things turn bad, and the operational review processes that keep a system healthy over time. AI-built products often ship fast and instrument late — so this is where velocity quietly borrows against reliability.

• Risk rises whenthere’s little visibility into production, incidents are handled ad hoc, on-call is informal, and no one owns operational health.

Buy-side specific, and where value is won or lost: how well the target’s engineering organization and technology fit the acquirer’s. I assess org and cultural compatibility, technology and platform alignment, and the real cost and risk of integration — so the committee understands what it will actually take to combine the two, not just what it takes to buy.

• Risk rises whenstacks, cultures, or operating models are incompatible enough to make integration far costlier than modeled.