The Product Works. That's Not the Question Due Diligence Is Asking.
Every investor writing a check, and every acquirer signing an LOI, runs the same test before they commit: does the product work. Demo the flow, check the metrics, talk to a few customers. If the answer is yes, the deal moves forward.
That test answers the wrong question. A product working today says nothing about whether it survives the next eighteen months, the next funding round's scale, or the next engineer who has to touch code the original team never documented. Working and built-to-last are different claims, and the gap between them is exactly what a real technical due diligence exists to find.
The assumption everyonemakes, and why it's wrong
Commercial traction gets treated as a proxy for technical health. Paying customers, a working demo, a metrics dashboard that trends up and to the right, all of it gets read as evidence the underlying system is sound.
It isn't evidence of that at all. A product can serve real customers profitably while running on architecture that will not survive its next order of magnitude of scale, on a codebase where one engineer's undocumented mental model is the only thing holding authentication together, on compliance gaps that are invisible until a regulator or a breach makes them very visible indeed. None of that shows up on a product demo. Some of the worst findings show up from something as simple as opening a browser's developer console on the live product and reading the raw response payload: data sitting right there in the API response that the UI was simply told not to render. The UI looked careful. The access control behind it wasn't.
What we're actually looking for
A real technical due diligence isn't a code review. A code review asks whether the code is well-written. Due diligence asks a different, harder question: if this company scales three times, or its key engineer leaves tomorrow, or a regulator asks for its data handling practices in writing, does the story hold together.
That means looking in the places a demo never shows you. Who actually holds the tribal knowledge, and whether any of it is written down anywhere a new hire could find it. What happens to personal data end to end, not what the privacy policy claims happens, but what the code actually does with it, where it's stored, who can access it, how long it lives, whether deletion requests are actually honored or just marked as handled. Where the single points of failure sit, which usually means one system nobody has touched in years because the person who understood it is gone.
The discipline is in how the testing itself gets run, not just what it finds. Authorization isn't tested once, it's tested across roles and across boundaries deliberately, a token valid for one account or one tenant deliberately pointed at another account's or another tenant's records, because the question that matters isn't "does the login work," it's "does the system actually enforce who's allowed to see what, or does it just trust the UI to ask nicely." Every finding gets sorted into one of three honest buckets: confirmed, meaning we reproduced it and can show exactly how; verified secure, meaning we tried to break it and couldn't, which is worth stating explicitly rather than just staying silent about the things that held up; and needs clarification, for anything we couldn't fully validate because the application's own workflow wouldn't let us generate the test conditions we needed. That third bucket matters more than it sounds like it should. A report that only ever says "confirmed" or silently skips what it couldn't test is a report you can't fully trust. One that tells you plainly what it tried and couldn't finish is a report you can.
What we consistently find
Across the technical due diligence engagements we've run, one pattern holds regardless of industry: the gaps cluster in the same five places every time.
Access control that's broader than anyone intended, admin privileges handed out during an early scramble and never revisited. Data handling that doesn't match the privacy policy's claims, not out of bad faith, but because nobody audited the actual data flow against what was promised on paper. Architecture called microservices in the pitch deck that ships and deploys as a single monolith in practice. Test coverage that exists but tests the happy path exclusively, so it passes every time while the actual failure modes go unchecked. And tribal knowledge concentrated in one or two people, undocumented and non-transferable, a single-point-of-failure risk that never shows up on a cap table but should worry an acquirer more than most things that do.
Picture the pattern concretely. A platform with tens of thousands of active users, profitable, growing, a clean-looking codebase on the surface. Dig into how a user's data actually moves through the system, and the deletion flow marks a record as deleted in one table while three other tables, built at different points by different engineers solving different problems, still hold the original data indefinitely. Nobody built this maliciously. Each addition made sense in isolation. Nobody had ever traced the full path end to end until we did. That's not a hypothetical, it's the shape of what a genuine data-handling audit surfaces almost every time it's run properly, because most systems accumulate exactly this kind of drift and nobody goes looking until someone's forced to.
The number that actually matters
Across the engagements we've run, the finding count per platform has ranged from the low dozens to well over a hundred production-relevant gaps, security, compliance, and architectural, combined. Not cosmetic findings. Findings that become an incident, a regulatory exposure, or a scaling wall within the first eighteen months of ownership if nobody addresses them first.
That range is wide on purpose. It reflects real variation across real companies, not a single benchmark we're trying to hit. What doesn't vary is the existence of the gap itself. Every engagement finds one. The only question due diligence answers is how large it is, and whether it's a manageable remediation plan or a reason to walk away from the deal entirely.
Why this matters more than the code review it looks like
A founder who's never been through a real technical due diligence tends to assume their own team would have caught anything serious. That assumption is exactly backwards. The team that built the system is the team least likely to see its own blind spots, because the tribal knowledge that's missing is missing precisely because it lives in someone's head, not because anyone's hiding it.
An investor who skips this step and relies on a product demo and a founder's confidence is buying the visible 90% of a system and inheriting the invisible 10% sight unseen. That invisible 10% is where the real risk always sits, and it is completely knowable before the check clears, if someone actually goes and looks.
If you're on either side of that transaction, writing the check or preparing to receive one, this is the audit that tells you what you're actually buying, or what you actually need to fix before someone else looks. We built this practice because every deal we've touched needed it. If you're facing one, it already exists.
If this is a problem you're facing right now, get in touch.
