Services / Technical Due Diligence
Find out what you're buying beneath the demo.
I review a software company's codebase, infrastructure, security risks, and team capability before you invest or acquire. You get a written account of what is there, what is uncertain, and what the likely post-acquisition work will involve.
$5,500. Typical review window: two to three weeks. 50% upfront.
A report tied to the acquisition decision
The question is whether the product, systems, and team can support the business plan after the transaction. A clean demo won't show a fragile deployment, a permission rule checked in only one path, a critical service only one person understands, or a cost that rises sharply with usage. I look for issues that could change your price, integration plan, staffing, or timing.
What I examine
Code and product
The architecture, main user paths, tests, dependencies, maintainability, and gaps between what the product claims and what the code enforces.
Infrastructure and security
Hosting, deployment, backups, access controls, external services, recovery paths, and material security or data-integrity risks visible within the agreed access.
Team and ownership
Who understands and operates each critical part, where knowledge is concentrated, and what capacity the team has to maintain or extend the system.
Post-acquisition work
A prioritized view of what to stabilize, document, replace, or leave alone, with effort estimates and assumptions a buyer can challenge.
What the report makes visible
Each material finding states the observed behavior, why it matters to the transaction, the evidence behind it, and what I would check or change next. A report also names access limits and unanswered questions. It doesn't turn a missing repository or an untested production path into a confident claim.
Example from my own product
A tool loop excluded a sensitive set of actions from the menu shown to an AI agent. The code comment called that a safety rule. I traced a call through dispatch and found the menu filter didn't enforce it: a known tool name could still execute if the calling key had the grant. I moved the denial to dispatch and added checks that call the excluded domain with a fully granted key.
This came from my own product, not an acquisition engagement. Read the full write-up to see the claim, failure path, repair, and limit I recorded.
How the review works
Agree on access and questions
We identify the transaction stage, decision date, and systems in scope. I ask for code, deployment and operating records, relevant agreements or architecture notes, and time with the people who maintain the product.
Inspect and verify
I read the implementation, follow important user and data paths, run available checks, and test claims that could affect the decision. I record where access prevents verification.
Report the decision risks
You receive ranked findings, supporting evidence, open questions, and a post-acquisition work picture. We review the report together before you decide how it affects the deal.
Who this is for
- A buyer or investor who needs an independent technical view before a software transaction.
- An operator who needs a realistic first-quarter plan for the acquired system.
- A founder preparing for scrutiny and wanting to know which claims can be backed by evidence.
The review's scope depends on access to the target system and people. It isn't a penetration test, financial audit, or legal opinion.
Tell me what you're evaluating.
We can discuss the transaction stage, the access available, and the decision date before setting the review scope.
Request a 30-minute call