Start with the decision the report must support
An investment review, acquisition handover and internal architecture assessment need different evidence. Establish the decision before choosing a checklist. A repository can demonstrate code structure, but it cannot establish production reliability without operational evidence. An interview can explain intent, but does not prove that a restore procedure has been exercised.
This service covers software engineering risk within an agreed scope. It does not provide company valuation, legal advice, financial due diligence or property inspection. It is also not a penetration test, compliance certification or guarantee that a system has no vulnerabilities. Those specialist assessments need their own qualified providers.
Software technical due diligence checklist
- Build and release: identify the reviewed commit, reproduce the documented setup and trace a deployed version back to source. Record missing access.
- Architecture: map service and crate boundaries, external dependencies and the path through one consequential business operation.
- Rust workspace health: inspect feature flags, dependency policy, unsafe boundaries, lint enforcement and the difference between compiled and executed tests.
- Async operation: examine blocking calls, cancellation, queue limits and task ownership. Ask what happens when a downstream dependency stops responding.
- Data integrity: establish write acknowledgement, concurrency control, migration and recovery behaviour. For event sourcing, inspect replay and schema compatibility.
- Operational readiness: review available alerts, incident evidence, backup restoration and runbooks. Identify tasks only one person knows how to perform.
- Security hygiene: inspect available evidence for access boundaries, secret handling and dependency checks without presenting the review as a security certification.
What the technical due diligence report contains
The report opens with scope: repositories, revisions, environments, evidence supplied and exclusions. Findings separate an observed failure from an inferred risk and an unverified claim. Each finding links to the evidence that supports it and explains the consequence for the decision being made.
A risk register identifies what needs attention, why it matters and how a follow-up check would establish resolution. The report also records operating dependencies and handover questions. Recommendations are tied to acceptance evidence, so a future reviewer can determine whether the proposed work solved the problem.
Illustrative finding: recovery evidence is missing
This is an example of report structure, not a finding about a client. Suppose a runbook describes backup restoration but the review receives no restoration result. The observed fact is that the supplied evidence does not demonstrate recovery. It would be inaccurate to conclude that backups are broken, or to mark recovery as verified.
The consequence is uncertainty about recovering the service after data loss. A bounded verification step is to restore an agreed backup into an isolated environment, compare expected records and run the critical product flow. The result should identify the backup, application revision, configuration and remaining exceptions. That evidence can resolve the question without turning an assumption into a verdict.
Evidence to prepare
Start with a non-confidential system overview and the decision you need to make. Repository access, architecture notes, CI results, release information and operational documents can then be agreed under the engagement's confidentiality and access terms. Supply redacted examples where customer information is unnecessary.
Access should be limited to the review's needs. Do not send credentials or production data through the enquiry form. If production access cannot be granted, say so early: a scoped code review can still be useful, provided its report does not claim to verify production behaviour. Any test that changes a system requires separate agreement.
Why Rust and event-sourced systems?
Wolven Tech's published engagement summaries cover Rust desktop, service and event-sourced systems. Its own product, AllSource, provides public material on event storage and replay. These establish relevant technical context; they do not replace examining the specific system under review.
If the primary need is to make changes with the existing team, consider Rust consulting and architecture review. A diligence assessment can identify implementation work, but that work requires an agreed scope rather than being assumed to be included in the report.