Most technology diligence confirms what a target has. The expensive risks live in how it runs.
The diligence report was green. The data room was tidy, the uptime numbers were respectable, and the org chart had no obvious holes. Eighteen months later the platform is straining under twice the load, the roadmap has quietly slipped a year, and the technology cost base has grown faster than revenue. Nobody lied during the process. The questions were just too shallow.
Most technology diligence is built to verify artefacts: licences, architecture diagrams, security policies, uptime dashboards, headcount. Artefacts are easy to request and easy to tick. But the risks that erode value after completion are rarely artefacts. They are operating characteristics, and they only show themselves under pressure.
Growth is the pressure that exposes them. The platform that handles today's volume was never tested against the volume in the investment thesis. The delivery team that ships adequately at current scale was already at capacity before the deal. The cost base that looked stable was stable only because nobody was growing it.
Scalability was assumed, not tested. The architecture diagram says horizontal scaling. The production system has never been pushed past Tuesday's peak. The gap between those two statements is where re-platforming budgets come from.
Technical debt taxes every initiative. Debt rarely appears as a line item. It appears as velocity: every roadmap item takes longer than it should, every integration costs more than quoted, and every good engineer spends a day a week working around decisions made years ago.
The platform lives in two heads. Key-person risk hides behind good documentation right up until the person who wrote the documentation resigns. Succession, retention exposure, and the real bus factor deserve the same scrutiny as the code.
The cost base expands on contact with growth. Cloud spend, licensing tiers, and support contracts that look proportionate today are often priced to jump at exactly the thresholds the thesis plans to cross.
The difference is between artefact questions and operator questions. An artefact question asks whether a disaster recovery plan exists. An operator question asks when it was last tested, and what broke. An artefact question asks for the org chart. An operator question asks who would have to resign for the roadmap to stop. An artefact question asks for the cloud bill. An operator question asks what the bill looks like at three times the transaction volume.
The output of good diligence is not a technology opinion. It is a set of priced consequences: what to reflect in the deal, what to plan for day one, and what to put in the first 100 days. That requires the assessment to be run by someone who has owned these decisions and lived with their consequences, and it requires every finding to be translated into investment risk, execution risk, and value impact.
Bridgepoint runs eight-domain technology due diligence for Australian mid-market private equity, with AI risk and readiness assessed throughout and findings framed in commercial terms. How our Tech DD works.
A scoping call is confidential and obligation-free.
