Technical due diligence

Context

• Buy-side and sell-side teams need engineering reality to match financial models—debt, scalability limits, security posture, and key-person risk.
• Boards and PE sponsors increasingly ask for independent views that go beyond vendor demos or management slides.
• Large vendor or cloud selections fail when evaluation criteria ignore run-state operations and integration boundaries.

Problems addressed

• Codebase and platform age are mistaken for risk without understanding modularity, test coverage, and deployment discipline.
• Security is summarised as “SOC 2 pending” instead of control design, blast radius, and incident rehearsal.
• Architecture reviews stop at diagrams and miss failure modes: data consistency, rollback, and cross-team ownership.
• Vendor bake-offs compare feature matrices while ignoring APIs, data export, and what happens after go-live.

What this work involves

• Targeted code and configuration sampling with explicit criteria: coupling, deployability, observability, and data governance touchpoints.
• Interviews with engineering, security, and operations mapped to a shortlist of verified claims versus observed practice.
• Threat- and failure-oriented walkthroughs: backup/restore, key custody, segmentation, and privileged access—not generic compliance grids.
• Written findings with severity, remediation cost bands, and dependencies so legal and commercial teams can negotiate from the same facts.
• Vendor or platform scorecards tied to your operating model (sites, regions, regulatory context), not abstract “best practices.”

Relationship to services

Capability pages describe what kind of technical work sits behind advisory, security, and delivery engagements. Commercial framing, pricing, and engagement shape live under Services.