Independent assessment of a company’s product, technology, architecture, engineering organization, delivery capability, and technical risk before an investment, acquisition, partnership, or major strategic decision.
What I assess
The scope is tailored to the transaction or decision and may include:
- Product maturity and alignment with the business model
- System architecture, scalability, reliability, and technical debt
- Engineering organization, leadership, processes, and key-person dependencies
- Software delivery capability and roadmap credibility
- Infrastructure, security, data, integrations, and third-party dependencies
- Intellectual-property and documentation risks
- Technology costs and likely future investment requirements
- Ability to scale, integrate, transform, or support the proposed growth plan
What you receive
You receive a clear, decision-oriented assessment rather than a generic technical report.
Deliverables can include:
- Executive findings and material-risk summary
- Risk register with severity and business impact
- Architecture and product assessment
- Engineering organization and delivery assessment
- Technical debt and remediation priorities
- Investment requirements and indicative roadmap
- Deal questions, conditions, and post-transaction priorities
When to bring me in
Technical due diligence is valuable when you are:
- Evaluating an acquisition or investment
- Preparing a company for sale or fundraising
- Assessing a strategic technology partner
- Validating claims made by a vendor or development team
- Taking responsibility for a troubled or poorly documented platform
- Planning post-acquisition integration or technology transformation
Beyond the report
When useful, I can remain involved after the assessment to help leadership validate the remediation plan, select vendors, establish technical governance, or guide execution.
The assessment remains independent. Any follow-on involvement is agreed separately and based on the organization’s actual needs.
Make the decision with clarity
A polished product can hide architectural, organizational, and delivery risks. A complicated codebase can also conceal a fundamentally strong business.
The purpose of due diligence is to distinguish between the two and explain the consequences in language decision-makers can act on.