Advisory
What a technical due diligence report should tell you before you sign
The product works. Customers are using it, the demo went well, and the business plan assumes the platform will carry the next stage of growth. At some point in the deal, someone asks whether the code underneath is sound, and nobody at the table can answer from experience.
Simon Bestbier
5 min read
A technical due diligence report is meant to fill that gap. It is an independent review of a platform's code, architecture, security and the team behind it, written for the people making the decision. A good one gives you grounds to adjust the price and terms. A weak one confirms that the software exists and leaves the hard questions unanswered.
The way to tell them apart is to read the report in the order your board will.
The executive summary should let a board decide without reading further
Start at the front. The executive summary is the part most of your board will read, so it has to work on its own. In plain language, it should say whether the platform can support the business plan, which risks matter now and which can wait, and what fixing the urgent ones is likely to involve.
If the summary needs a developer to translate it, the report was written for the wrong reader. Technical detail belongs in the body, where the people who will fix the code can find it.
Every area needs a rating you can compare
A list of observations is hard to act on. A report should rate the risk in each area it covers, so you can see at a glance where the problems cluster. A red, amber or green rating per area works well: red for a risk that should affect the deal or be fixed before anyone builds further, amber for something to plan and budget for, green for an area in good order.
Each rating should point to specific findings in the code, so your own developers, or another reviewer, can check how it was reached.
The review areas answer four questions an investor asks
The areas a review covers can look like a technical checklist. Grouped by the question each one answers, they read more like a set of investment risks.
Can the platform grow with the business? Architecture, scalability and stability. The report should say how the system is structured and whether that structure fits what the business needs it to do next. It should show where the platform will slow down or fail as users, data and transactions grow, and how it behaves when something it depends on goes down.
Could it become a liability? Security, data protection, third-party dependencies and the use of AI. This covers how users sign in, what they can reach, and how the code handles secrets and user input. It covers how the platform collects, stores and deletes personal data, measured against POPIA and GDPR. It also covers which open-source libraries and outside services the product relies on, how they are licensed, and what data any AI service receives.
A platform that only one developer understands is a risk to the investment, however good that developer is.
What will it cost to keep? Code quality, technical debt and documentation. Here the report should tell you how easily a new developer could pick up the code and which shortcuts will need budget after the deal closes, with an estimate of how much. It should also say whether the documentation would let someone else run the platform.
Who holds it together? Team, process and delivery. A review should look at how code is reviewed, tested and released, and how much knowledge sits with one person or one supplier. This is the area founders most often underestimate, because the person who built the platform rarely sees themselves as a risk.
The fix list should arrive in order
Findings without priorities leave the hardest decision to you. The report should end in a list of fixes, most urgent first, with enough detail for a development team to estimate the work.
After the deal, the list becomes the first technical plan for the platform. If parts of it have to happen before money moves, it also gives you something concrete to attach conditions to.
Know what a review can and cannot see
A review looks at the platform as it stands when the reviewers get access. The reviewers read the code and talk to the people who wrote it. They change nothing, so the business under review only needs to give read-only access to its code repository and a few sessions with the lead developer or product owner. Documentation helps, but a review should not depend on it being complete.
What a review cannot do is predict how the team will behave once the deal is done. That is why the team and process findings deserve as much attention as the code findings.
Timing matters too. Depending on the size of the platform, a review takes two to six weeks. If a deal date is fixed, agree the reporting date at the start, and ask for anything serious to be raised straight away so you can act on it while the review continues.
Independence decides whether you can trust the findings
Ask who wrote the report and what they stand to gain from it. A reviewer hoping to win the rebuild has a reason to find more wrong than there is. A reviewer close to the founding team has a reason to find less. A review run as a separate engagement, with no build work attached, removes both pressures.
Before you sign, you should be able to read one summary and know what you are buying, what it will cost to put right and who it depends on. If the report in front of you cannot tell you that, it has not done its job.
We carry out independent technical due diligence for investors and for businesses about to build on a platform. Tell us what the platform does, who built it and whether a deal is waiting on the answer.
