Taking over a codebase someone else built

Whether the previous developer went quiet, the relationship ended badly, or an AI tool got you partway there and stalled, taking over an existing codebase is a different job from starting fresh, and it needs different questions.

What to ask before hiring anyone

“Will you audit before you touch anything?” A developer who jumps straight into fixing without understanding what’s actually there first is guessing, and you’re paying for the guesses either way. An audit that produces written findings, before any billable fix work starts, protects you from a quote based on assumptions.

“What happens if it’s not worth saving?” Some codebases genuinely are better rebuilt than repaired, and you want to hear that answer before paying for either path, not after several weeks of fixes on something that needed a rebuild from day one.

“Do you check what’s actually deployed, or just what’s in the code?” This question filters for experience more than any other on this list. Managed platforms and AI builders can have configuration, server functions or environment settings that exist only in the live deployment and are absent from any exported code. A developer testing only the code repository can miss real, working parts of the app entirely, and just as easily miss real, broken parts.

“How do you handle access?” You should be granting access deliberately, to specific things, when they’re needed, not handing over every password on day one. A structured request for what’s needed and why is a good sign.

What to prepare before the handover

• Every account and its owner: hosting, domain, database, payment processor, email service, and who currently has admin on each.
• Any documentation that exists, even informal notes. Something is better than nothing, and its absence tells the new developer what to expect.
• A plain description of what’s actually broken or missing, in your own words, not guesses at the technical cause. “Customers can’t complete checkout” is more useful than “I think it’s a webhook issue” if you’re not certain it’s a webhook issue.
• Contact with the previous developer, if any is possible. Not required, but even a short handover conversation can save real diagnosis time.

What the first weeks should actually look like

Week one, an audit, not fixes. Expect a written report: what exists, what’s broken, what’s risky, and a plan with a price attached. If a developer starts pushing changes to your live app in week one with no audit behind it, that’s a red flag, not a sign of speed.

A scoped plan before ongoing work. Fixed price, named milestones, for whatever the audit surfaces as necessary. Open-ended hourly work on an unfamiliar codebase is how budgets run away, because neither of you can tell how much is left to find.

Access granted in stages, as the plan requires it, not all at once on day one.

The audit is the part that protects you

Not the previous developer. Not the new one. You. A proper audit means the person taking over understands what they’re inheriting before either of you commits to a number, and it means you have a written record of the codebase’s real condition, independent of whatever story led you to this point.