We are occasionally asked to review a codebase before an acquisition or an investment. Two weeks, a written report, risks ranked by the cost of being wrong.
What we look at
- Change history, not just the code. How long does a typical change take to land? Who can land it?
- The data model. Schemas outlive frameworks. A confused schema is the expensive kind of debt.
- Operational reality. Backups, restores, monitoring, secrets handling, who has production access.
- Dependency and licence exposure. Both the abandoned packages and the ones with terms nobody read.
The findings that recur
Four things come up in nearly every review: no tested restore procedure, one person who is the only route to production, business rules duplicated between the front end and the database, and a test suite that is large but does not fail when the product breaks.
None of them are reasons to walk away. All of them are reasons to adjust a number.