Technical Questions Worth Asking Before You Inherit a Codebase

Whenever a team or a business takes over an existing codebase — through an acquisition, a new engineering partner coming on board, or simply inheriting a product from a previous team — there's a predictable gap between what the code looks like on a quick review and what it actually costs to work with day to day. A handful of specific questions tend to surface that gap faster than a general "how's the code quality" impression ever does.

"What breaks if we deploy on a Friday?"

This question reveals more about operational maturity than almost any other single question. A team that can answer confidently — "nothing unusual, our deploy process is the same every day" — has real deployment discipline. A team that hesitates, or has an unwritten rule about not deploying before a weekend, is telling you the deployment process has known fragility that hasn't been fixed, only worked around.

"What's the oldest dependency we're still running, and why hasn't it been updated?"

Every codebase has some outdated dependencies — that alone isn't a red flag. What matters is the answer to "why not updated." A good answer: "it's scheduled, low priority, no known issues." A concerning answer: "we tried once and it broke things we didn't fully understand, so we stopped." The second answer tells you there's fragility nobody has fully mapped, which is a very different risk profile than simple technical debt.

"If our top three engineers left tomorrow, what would we lose?"

This surfaces bus-factor risk — how much critical knowledge exists only in specific people's heads rather than in documentation, tests, or code that's legible to someone new. A codebase can look clean on the surface and still have a devastating bus-factor problem if the person who understands the trickiest, highest-risk part of the system is one specific individual who's never had reason to write it down.

"What's not covered by tests, and why?"

Not "what's our test coverage percentage" — that number is easy to game and doesn't tell you what actually matters. The useful version of this question is qualitative: which parts of the system have no meaningful test coverage, and is that because they're low-risk and stable, or because they're the parts everyone's afraid to touch and nobody's had time to properly cover? Those are very different situations that produce the same coverage gap.

"How long does it take to onboard a new engineer to be productive?"

This is a proxy for both documentation quality and actual system complexity. A short, confident answer suggests the codebase and its context are genuinely legible to a newcomer. A long or vague answer — especially one involving "they mostly learn by asking around" — tells you critical context lives in people's heads and conversations, not anywhere a new person can find it on their own.

"What's the last incident that surprised the team, and what did you learn from it?"

Every system has incidents; that's not the signal. The signal is whether the team can articulate what they learned and what changed afterward. A team with a clear, specific answer has a real feedback loop between incidents and improvement. A team that struggles to recall a specific incident, or describes the same category of problem recurring without any process change, is telling you incidents aren't being converted into actual fixes.

"What would you build differently if you started over, and why haven't you?"

This is the most revealing question of the set, because the answer usually surfaces the real, specific technical debt — not the generic "the code is old" complaint, but the actual architectural decision someone made under a deadline that's now costing real time. The "why haven't you" half of the question matters just as much: it tells you whether the constraint is prioritization, cost, risk aversion, or genuine uncertainty about how to fix it safely.

What these questions have in common

None of them are about code style, and none of them require reading the codebase line by line before you can ask them. They're about surfacing operational maturity, hidden fragility, and where institutional knowledge actually lives — the things that predict how expensive a codebase will be to work with going forward, in a way that a surface-level code review usually can't.