Get the technical truth
An independent technical review should answer the decision in front of you, show what was tested and make its limits clear.
A decision you can recognise
Find the decision before choosing the review
Constructed example: a supplier says a product is ready, but the sponsor cannot reproduce the claimed recovery test. The first deliverable is a traceable finding: the claim, actual evidence, reproduction and consequence.
A depth audit answers whether completion is evidenced. An architecture review tests a design decision. Diligence examines investment exposure. Choose the question first; the report should leave someone able to make that decision.
Need to take this to a board? Read or download the buyer decision pack →
First name the decision
Is the platform likely to carry the next three years of growth? Can agents change the code without creating a mess nobody can detect? Is a supplier’s claimed-complete product actually complete? What risk and cost are you buying in an acquisition? These are different questions. A generic green/amber/red assessment will make them look alike and leave the board no closer to a decision.
We agree the question, the evidence available and the boundary of the review before inspection. Source, architecture, deployment records, contracts, tests, incident history and the people who run the system may each matter; the mix depends on the decision. A finding states the claim, the observation, how another person can reproduce it, what it could cost the business and what evidence would change our conclusion. If material is unavailable, the report says so. Missing access is not a clean bill of health.
Four different kinds of answer
An Architecture Review asks whether the system’s boundaries, data ownership, recovery design, scaling assumptions and running cost hold. Its risk register and remediation roadmap let a sponsor choose which change to fund first.
An Agentic-Ready Codebase Analysis tests whether an AI agent can locate the real specification, make a bounded change and run checks capable of exposing a bad one. It is not a tool-buying recommendation. You get an eight-part evidence score and a sample failure-capable gate.
A Depth Audit examines a delivery claim. We follow representative acceptance criteria into actual behaviour, tests, operations and handover, then report where the product is complete, hollow or unproven. The point is an answer a buyer can use, not the performance of being sceptical.
Technical Due Diligence connects engineering facts to an investment or acquisition decision: cost to serve, key-person dependence, security and data liabilities, licensing, recovery and the work hidden behind a growth forecast. It uses the buyer’s template and surfaces red flags plainly. The audit cannot substitute for legal or financial diligence; it makes the technical exposure legible to those disciplines.
What leaves the room
A written finding and decision trail: scope, material examined, observations, severity, reproductions, evidence gaps and a practical path through them. We separate a demonstrated defect from a risk and an inference from a verified fact. Where a claim is important, the check should be capable of proving us wrong.
Bring the decision you need to make and what you can share. We will propose the smallest review that genuinely answers it, then quote its fixed boundary. See the catalogue and prices or send the brief.