The Due Diligence Question Investors Don't Ask (But Should)
Most technical due diligence, done from the investor side, asks a narrow set of questions: what's the stack, is the code reasonably clean, does the team seem competent. Those questions get answered in a two-hour call and a look at the repo. They rarely surface the thing that actually determines whether a codebase survives its own growth.
The question that matters more is one investors rarely think to ask, and founders almost never volunteer:
If your two most senior engineers left next month, what would stop working and how would anyone know?
Why This Question, Specifically
Every early-stage codebase has load-bearing knowledge that never made it into documentation, tickets, or comments the reason a particular queue is configured a certain way, the workaround for a third-party API's undocumented rate limit, the tribal understanding of which service is safe to redeploy during business hours and which one absolutely is not. This isn't a sign of a badly run team. It's what happens naturally when a small team moves fast and the person who made a decision is also the person who remembers why.
The problem isn't that this knowledge exists. It's that most teams have no idea how much of their system depends on it until someone who held it is gone.
What Shows Up in a Real Audit
Bus factor, measured, not assumed. Not "do you have documentation" but a genuine walk through: for each critical system, how many people could debug a production incident in it without pulling in the original author? A bus factor of one on a payments-adjacent service is a specific, quantifiable risk — the kind that belongs in a term sheet conversation, not a footnote.
Dependency rot. Which core dependencies are on unsupported versions, which third-party APIs the business depends on have no fallback, which infrastructure choices were made under a deadline and never revisited. None of this is visible from a demo. All of it is visible from a dependency audit and a few honest conversations with the engineering team.
The gap between the pitch architecture and the actual architecture. Pitch decks describe systems as clean, service-oriented, and well-tested. Production systems, especially pre-Series-A, are frequently a monolith with good intentions. That gap isn't disqualifying, it's normal. But it needs to be known, priced, and planned for, not discovered after the check clears.
Whether the team can explain their own trade-offs. A team that can articulate why they chose a shared-schema multi-tenant model over schema-per-tenant, and what would trigger a migration, is in a fundamentally different risk category than a team that made the same choice by default and has never revisited it.
Why This Gets Skipped
Technical diligence often gets compressed into a checkbox exercise because the investor side doesn't have engineering depth on staff, and the founder side has every incentive to keep the conversation at the pitch-deck level. Neither party is being dishonest, the incentive structure just doesn't naturally produce the harder conversation.
The Decision, Not the Checklist
None of this requires an adversarial audit that makes founders defensive. What it requires is treating technical due diligence as a genuine risk-pricing exercise rather than a formality for investors, so capital gets priced against real risk instead of pitch-deck risk; for founders, because the team that can answer the bus-factor question honestly is the team that's actually derisking itself, raise or no raise.
Get that framing right, and due diligence becomes useful to both sides of the table. Skip it, and the first real answer to "what happens if the senior engineer leaves" arrives during an incident, eighteen months after the round closed.
// keep going
Want this kind of thinking applied to your stack?
An appraisal is the fastest way to find out where your architecture is quietly costing you.