Before an acquisition, a fundraising round or a buyout, the technology often decides the real value of a company that sells a data platform. A stack that demos well sometimes cannot hold the promised load. I run that independent evaluation, from code down to vendor contracts.
What the due diligence examines
The architecture and its real ability to scale, measured rather than declared. Technical debt where it will hurt: closed dependencies, missing replication, backups that were never restored. Operating costs and their trajectory, including cloud egress. Vendor dependencies and the realistic exit path. Finally key-person risk, when a single person understands the system.
Deliverables
A prioritized risk report with costed fixes, directly usable as a negotiation argument. Each risk carries a probability, an impact and a remediation cost, backed by measurements taken on the platform itself. References available under NDA.
This is neither financial audit nor litigation expertise: it is the engineering evaluation a transaction is missing when the value rests on the platform.
FAQ
When should technical due diligence run?
The right window opens between the letter of intent and the financial audit, while technical access is still negotiable and the findings can still move the price. A due diligence run after closing only documents problems; it no longer prices them.
How long does a technical due diligence take?
Five to fifteen days depending on platform size and system access. A week is enough for a documented stack with observability access; count triple when documentation is missing and measurements must be rebuilt from logs.