Choosing help to rescue a build another developer abandoned

The worst move a buyer makes when inheriting an abandoned build is rushing to the first developer who says they can "salvage it." You're already stressed about lost time and money. A fresh panic is a poor counselor. The real challenge isn't finding someone willing to unpick another coder's work—it's finding someone who'll do it honestly and won't repeat the mistakes that left you stranded the first time.

Rescuing an abandoned project is a fundamentally different hire than building from scratch. The developer you need must be forensic and diplomatic at once: able to read hostile code, diagnose why it failed, and own the work without blame-shifting. Most developers will quote you a rebuild rather than admit the original is salvageable, and some won't—they'll try to patch it and charge you twice.

Reading the codebase is your first filter

Before you hire, ask each candidate to spend 2–4 hours examining the abandoned code and giving you a written audit. Not a fix estimate yet—just a diagnosis. What state is the code in? Are the tests passing? Can they run it locally? Is the database schema sound? Did the previous developer leave documentation, or only cryptic comments?

This audit costs you a modest amount upfront, but it screens out developers who won't take the time to understand what they're walking into. It also gives you proof of what you're actually dealing with. A developer who balks at this step, or who quotes you a full rebuild without reading the code, is signalling that they'll work blind and charge accordingly. The candidate who writes a thoughtful audit—even if the news is grim—is already thinking like a problem-solver, not a replacement salesman.

Can they commit to continuity or honesty about a rewrite?

You'll get three answers: some developers will claim they can continue the original work; some will say it's salvageable but needs careful refactoring; others will tell you a rebuild is the only sane path. The second answer, delivered with evidence from the audit, is the one you should trust most.

Ask each candidate directly: under what conditions would you recommend continuing the old code, and under what conditions would you recommend starting over? Listen for nuance. A developer who says "we'll salvage it" for every project is as unreliable as one who says "we'll rebuild it" for every project. The honest ones hedge. They say things like, "The API layer is sound, but the frontend is coupled so tightly we'd spend more untangling it than rewriting it."

Portfolio work in your language and architecture

You need someone who has shipped projects in the same stack—the programming language, framework, database, deployment platform—as the abandoned codebase. If your app was built in Python and Django, and the candidate's portfolio is all Node and React, they're learning on your dime. They'll be slower, they'll make architecture choices that don't align with the original intent, and they'll struggle to debug problems specific to that stack.

Ask for two references who can speak to similar rescue or legacy work. Don't just take a name; follow up. A glowing testimonial about a clean greenfield build doesn't tell you whether someone can handle a codebase that's half-finished, under-tested, and emotionally fraught.

Clarity on what "done" means

The biggest point of friction in a rescue is scope creep disguised as necessary cleanup. Get the candidate to list what they will and won't do:

• Will they write tests for untested code?
• Will they refactor as they go, or only touch what's broken?
• Do they have a timeline for each phase (audit, stabilisation, new features)?
• How often will they deploy, and to which environments?
• If the original database is corrupted, who decides whether to migrate or rebuild it?

These aren't abstract questions. They separate a developer who'll deliver a working app in eight weeks from one who'll spend twelve weeks making the code beautiful while you're still debugging production errors.

Finding the right person to resurrect an abandoned build isn't about hiring the cheapest or the fastest. It's about hiring someone honest enough to tell you what the code actually is, experienced enough to navigate its specific tools, and disciplined enough to draw a line between fixing and perfecting. On Strove you can review past work and message developers directly with your audit findings; many will give you a thoughtful response before you hire.