# See the engineering behind the promise.

Technical due diligence

Assess architecture, delivery practices, maintainability and operational risk before investment or change.

## An evidence pack for an investment decision

Illustrative workflow.

- Product architecture: Boundaries, dependencies and ownership
- Delivery capability: Build, release and recovery evidence
- Risk register: Impact, confidence and remediation options



## Distinguish demonstrated capability from a claim

### Judge the product from a presentation

A convincing demo does not reveal release fragility, hidden dependencies or the effort required to support growth.

### Inspect the system and its delivery record

Trace important claims to code, configuration, test results and conversations with the people who operate it.

## What needs attention in your system?

Select the areas you want to discuss. The HTML page can download your selections.

- [ ] Architecture review: Examine the application boundaries, data model and dependencies against the intended business use.
- [ ] Delivery evidence: Review source ownership, release practices, tests and operational records.
- [ ] Decision record: Separate immediate risks from longer term work with the assumptions behind each recommendation.

## Separate demonstrated capability from an assertion

Review a software product’s architecture, maintainability and operating evidence against the decision you need to make. Identify material uncertainty and the work needed to resolve it.

Illustrative scenario, not a customer case study.

A growing Australian software product needs clearer ownership without immediately adopting distributed services.

Separate business capabilities behind explicit interfaces and prevent modules from writing into each other’s tables. Keep cross-module workflows visible in an application layer.

Verification: Track dependency cycles, change coupling and the effort needed to test one capability in isolation.

## Examine the system behind the presentation.

### Architecture review

Examine the application boundaries, data model and dependencies against the intended business use.

### Delivery evidence

Review source ownership, release practices, tests and operational records.

### Decision record

Separate immediate risks from longer term work with the assumptions behind each recommendation.

## Is this a valuation or a financial audit?

No. Technical due diligence informs an investment or acquisition decision by examining technology risks and delivery capabilities within an agreed scope.