When an investor or acquirer sends in a technical diligence team, founders tend to prepare by trying to make the codebase look good. This is the wrong preparation and it is also impossible in the available time. Diligence teams have seen many codebases and expect none of them to be clean. What they are actually assessing is whether the engineering leadership has an accurate picture of their own system, because a team that knows its weaknesses can be planned around and a team that does not cannot.
That reframes the work usefully. Rather than fixing things, write down what is true: the architecture as it actually is, the parts you would rebuild given time, the known scaling limits and when you expect to hit them, the dependencies you are uncomfortable about, the areas with poor test coverage and why. A document like that, offered up front, converts an investigation into a conversation. Diligence teams find these things anyway; the difference is whether they find them with you or despite you.
The findings that genuinely change deal terms are narrower than the anxiety suggests, and they are worth checking properly beforehand. Intellectual property ownership — every contributor, including contractors and former employees, having assigned their work. Open source licence compliance, particularly copyleft obligations in proprietary code. Personal data handling against applicable regulation. Single points of dependency on one individual. Security issues serious enough to represent an actual liability. Those five move price. Untidy code does not.
Key person risk deserves particular attention because it is the one founders systematically underweight. If one engineer is the only person who understands the payment reconciliation, or holds the production credentials personally, or is the only one who has ever performed a database failover, that is a finding. It is also fixable in weeks — pair someone, write the runbook, rotate the credentials into a shared vault — and far cheaper to fix before the question is asked than to answer honestly when it is.
Have the boring artefacts ready, because their absence signals something beyond their content. An architecture diagram that matches reality. A dependency inventory with licences. A list of every third-party service, its purpose and its data. Access control showing who can reach production and how that is granted and revoked. Incident history with what was learned. A restore that has actually been tested, with a date. None of these take long to produce and each one absent invites a question that takes longer to answer.
The tone to aim for is unembarrassed accuracy. Saying a component is poorly tested and here is the plan reads as competence. Saying everything is fine and being contradicted by a code scan reads as something worse than the original problem, because it changes what the other side believes about everything else you told them.
