A fair amount of the work we take on starts with code that already exists. Sometimes it was built in-house, sometimes by a previous agency. Either way, the first thing we do isn't write a line of new code.
Before anything else, we need to understand what we're working with. Not just technically — though that matters — but why it is the way it is. Code doesn't exist in a vacuum. Every structural decision, every shortcut, every comment that says "TODO: fix this properly" has a story behind it. Some of those stories are about time pressure. Some are about changing requirements. Some are about decisions that made sense then and don't anymore.
The things we pay most attention to early on are less about the quality of the code itself and more about how well it matches how the business actually works. A system that's technically elegant but doesn't reflect the real workflows of the people using it is usually harder to improve than one that's messy but closely mirrors the business logic it was built for.
We also look at test coverage, or the absence of it. Not because tests are a moral good in themselves, but because a codebase without tests is one where you can't make changes with confidence. Every modification becomes a guess. That slows everything down and tends to make developers conservative in exactly the places where they need to be able to move.
Documentation tells us something too — not just what exists, but what was considered important enough to write down. A system with no documentation isn't necessarily a bad one, but it usually means the knowledge lives entirely in the heads of whoever built it. When those people aren't around anymore, you find out quickly what wasn't written down.
None of this is about judging previous decisions. It's about building an accurate picture of what we're working with before we start making promises about what we can change. The businesses we work best with are the ones who give us the time to do that properly before the pressure to build something new kicks in.