What technical due diligence finds
Two weeks reading someone else's codebase before quoting a rebuild. The findings are rarely about code quality and almost always about coupling.
We will not quote a rebuild we have not read. Two weeks of technical due diligence comes first, and the client gets the report whether or not they continue with us. It has cost us work occasionally, which is the point of doing it that way.
The finding that changes a plan is almost never code quality. Ugly code is cheap to live with. What matters is coupling: how many things break when you change one, and whether anyone can tell you in advance which ones.
The second thing we look for is where the business logic actually lives. It is frequently not in the application. We have found pricing rules in spreadsheet formulas, in a database trigger, and once in a scheduled job whose author had left three years earlier. You cannot rebuild what nobody can state.
Then the operational reality. Can you stand the system up from scratch? Is there a test that fails when something is broken? What happens at 3am when the sync job dies — is there an alert, and does anyone own it? Systems that cannot be rebuilt from source are much more common than people admit.
The report we write is deliberately boring: what exists, what is risky, and what it would cost to fix versus replace, with effort ranges attached to each. Sometimes the honest recommendation is not to rebuild at all, and to spend a fraction of the budget on tests and observability instead.