How to choose a developer to fix a system you didn't build

Hiring someone to fix a system you didn't build means handing them a codebase they've never seen, often with incomplete documentation and no access to whoever built it. If you rush this choice, you'll end up with someone who either charges by the hour to reverse-engineer what should take a morning, or who patches symptoms instead of understanding root causes. The difference between a careful pick and a quick one can be the difference between a system that runs reliably for years and one that deteriorates faster after the fix.

The core problem is asymmetry: the developer knows nothing about your system yet, and you probably can't judge their technical depth until they start digging. That means your choice hinges on how they approach the *unknown*.

Code comprehension, not just coding speed

Ask candidates to walk you through how they'd start. The right answer involves reading, mapping dependencies, checking logs, asking questions—not immediately opening a text editor. Someone who's fixed other people's code learns to sit with unfamiliar architecture first. They'll want to understand why the bug exists, not just patch it. This takes longer upfront but prevents the "fix that breaks something else" trap.

When they ask you detailed questions about what the system does, what's changed recently, and where the failure happens, that's a signal they're thinking before acting. When they ask to see error logs, database schemas, or how the system is deployed, they're checking whether the bug is what it appears to be. Conversely, someone who jumps to solutions without clarification is gambling with your system's stability.

Also ask what they'd do if they hit something they don't immediately understand—a framework they've never seen, a design pattern that's unfamiliar, or dependencies that don't make sense. Their answer should involve learning the codebase, not rewriting it from scratch or bypassing it.

Track record with legacy systems

People who specialise in maintaining or fixing systems they didn't write tend to stay in that lane because it's valuable. Ask for a portfolio of similar work: previous clients, complexity of systems they've touched, and whether they've had to navigate code written in styles or tech stacks different from their own. This isn't about resume padding. It's about proof they can slow down and listen to what an existing system is telling them.

Also ask who they've worked with in similar situations. Can they give you a reference from someone who handed over a broken system and came away satisfied? An honest answer might be "I usually work in fintech and this will be my first e-commerce codebase, but here's what I'd do differently," which is better than false confidence.

Ability to diagnose before promising

Watch out for anyone who quotes a fixed price and timeline before they've read a single line of code. Legitimate unknowns exist when you're inheriting someone else's work. A careful developer will either charge an hourly rate for diagnosis, or give you a conditional quote ("I'll charge X for a two-day audit, then we'll know the scope").

Ask if they can spend a few hours isolated with the system before committing to a fix. Some will do this free or cheap as a scoping exercise. Others won't, and that's sometimes reasonable if they're established and busy—but they should still be clear that they're estimating blind. The ones to avoid are those who smile and promise a fixed price without hesitation.

Communication during the handover

You need someone who'll keep you informed as they work, especially if they hit something that changes the plan. This matters more than their communication style. Ask how they typically report progress: weekly updates, daily Slack messages, a shared doc where they log what they've found?

Also ask whether they'll document what they've changed and why. A good handover includes notes on what the bug was, what triggered it, what they did to fix it, and anything they recommend going forward. If someone's done this before, they'll have examples.

Trust your instinct about responsiveness. You're trusting someone with a system that's already broken; you need to believe they'll get back to you quickly if something goes wrong.

When you're ready to move forward, Strove lets you compare developers who've done this work before, review their client feedback, and reach out directly with all your specifics. Finding someone with a real track record of inheriting unfamiliar code is half the battle.