What we look for in a technical due diligence

Technical due diligence is often reduced to a code quality review. Code quality matters, but it is rarely what determines whether a platform can support the growth thesis.

The signals that predict problems

How long does onboarding take?

If a new engineer cannot get a working local environment in a day, every future hire pays that tax. It also usually indicates undocumented environmental dependencies that will surface during scaling.

What happens on a Friday afternoon?

Teams that will not deploy on a Friday are telling you their release process is not trustworthy. That constraint compounds directly into delivery velocity.

Who is the single point of failure?

Almost every codebase has one person who understands a critical subsystem. The question is whether the organisation knows who that is and is doing anything about it.

Is there a test suite people believe?

Coverage percentage is nearly meaningless. The useful question is whether engineers trust a green build enough to ship on it.

What we deliberately discount

Framework age, minor style inconsistency and a moderate amount of duplication are cosmetic. A five-year-old, well-maintained monolith with strong tests is a far better asset than a fashionable microservice estate nobody can deploy safely.