Architecture review and due diligence

An architecture review is an independent, fixed-scope assessment of a codebase and the infrastructure it runs on, written up as a report with findings ranked by risk, estimates for fixing the important ones and a plain-language summary for decision-makers. I do them for non-technical founders checking an agency's or a freelancer's work, for investors and acquirers who need technical due diligence before a deal, and for teams deciding whether to rebuild or refactor. A code audit of one codebase is the core of it; the technical review and code audit page covers that work more broadly.

Technical due diligence is an independent review of a company's software, infrastructure and engineering practices before an investment or an acquisition. It looks hardest at risk, cost and the team's ability to keep shipping, and it ends with a report the deal team can use.

The report holds diagrams of the system as it really is, findings on code quality, security, scalability, cost and delivery ranked by risk, estimates for the important fixes, a view of team and key-person risk, and a plain-language summary for decision-makers. Each finding says what was found, why it matters to the decision and what fixing it would take.

The review starts from the decision it supports: invest or not, rebuild or refactor, keep the agency or not. That decides what is in and out of scope and how deep each area goes. A due-diligence review for a deal looks hardest at risk, cost and the team's ability to keep shipping; a rebuild decision looks hardest at the architecture and the data model.

I read the code and its history, the infrastructure and its costs, the CI/CD pipeline, the monitoring and the incident record, and talk briefly with the team, because code shows what was built and conversations show why. The areas are architecture and data model, code quality and test coverage, security posture including secrets, dependencies and access control, scalability under realistic growth, cloud cost, the delivery process, and how much of the system depends on one person's knowledge.

The report includes diagrams of the system as it really is, drawn at the level of systems, containers and components so each audience can stop at the depth it needs. Each finding states what was found, why it matters to the decision, and what fixing it would take.

It is not a rubber stamp: the report says what I find, including when the system is sound and the money should go elsewhere. It is not a penetration test either; the security section reviews posture and design, and if active testing is needed, a security audit is scoped separately. And it is not legal, financial or tax due diligence.