Inheriting a Half-Finished Codebase: Rescue It or Rebuild?

A client comes to you with a project that's 70% done. The previous developer stopped responding. There's a repository, maybe some access credentials, and a deadline that's already passed.

They want to know two things: can it be saved, and how much.

The instinct is to say rebuild. It's cleaner, it's more billable, and reading someone else's unfinished code is genuinely unpleasant. But rebuilding a project that was mostly working is a bad outcome for the client and often a worse one for your margin, because "rebuild" projects have a way of expanding.

Here's how to make the call honestly.

First, get access to everything

Before any technical assessment, find out what actually exists. This step alone kills a surprising number of "rescue" projects.

• The code. All of it, with full history. A zip file with no git history is a bad sign.
• The hosting and deployment. Who owns the account, who can deploy.
• The domain and DNS. Frequently registered under the previous developer's account.
• Third-party services. Payment provider, email, storage, APIs. All the keys.
• Designs. Figma or otherwise, and whether the client owns them.

If the previous developer holds the domain or the production account and is unreachable, that's your first problem and it's a legal one, not a technical one. Recovery is possible but slow. Flag it immediately, because it can hold up a launch regardless of how good the code is.

The one-week audit

Do this as a paid, fixed-fee piece of work before quoting anything else. It protects you and it's genuinely valuable to the client even if they take the answer elsewhere.

Day 1 — can you run it?

Clone it and get it running locally. This is the single most informative hour of the whole audit. If there's a readme, working environment config, and it starts up, the previous developer was reasonably disciplined. If it takes two days of guessing at environment variables, that tells you what the rest will be like.

Day 2 — what's actually finished?

Ignore what the client was told. Click through the application and write down what works, what half works, and what's a stub. The gap between "70% done" and reality is usually large and always in one direction.

Day 3 — how is it built?

Not "is it beautiful." Ask:

• Are the frameworks current and supported, or three major versions behind?
• Is there a sensible structure, or is everything in one file?
• Are secrets committed to the repository? (Very common, and a security issue you must flag.)
• Are there tests? Any at all?
• Is the data model coherent?

Day 4 — the data model specifically.

This matters more than any other single factor. Code can be refactored incrementally. A data model that's fundamentally wrong — especially one that ignored multi-tenancy or has no concept of an audit trail — requires a migration under live data, which is where rescue projects go from profitable to painful.

Day 5 — write it up.

A short document: what exists, what's missing, what's risky, and two options with numbers.

How to decide

Lean toward finishing when:

• It runs, and the core workflow basically works
• The data model is sound, even if the code around it is messy
• Frameworks are current enough to be supported
• The remaining work is features, not foundations
• The client's deadline genuinely matters

Lean toward rebuilding when:

• The data model needs to change fundamentally
• Dependencies are so old that security patches aren't available
• It doesn't run locally and nobody can explain how it was deployed
• The "70% done" is actually about 30%
• Security is compromised in ways that touch user data

One honest note on estimation: taking over unfamiliar code is slower than writing your own, and everyone underestimates by how much. Whatever the remaining work looks like, add real contingency. If your estimate to finish is close to your estimate to rebuild, rebuild — because the finish estimate is the one more likely to be wrong.

The middle option people forget

You don't always have to pick one.

Often the right answer is: keep the parts that work, rebuild the parts that don't. Keep the database and the data if it's sound. Rebuild the frontend. Or keep a working payment integration that took someone weeks to get right, and replace everything around it.

This is usually the best outcome for the client and it's a more defensible quote than a full rebuild, because you can point at exactly what you're keeping and why.

Talking to the client about it

Two things to handle carefully.

Don't trash the previous developer. It's tempting, it makes you look good briefly, and it makes the client feel stupid for hiring them. It also makes them wonder what you'll say about them. Stick to specifics: "the data model doesn't support multiple users, which means X."

Be clear about what you're inheriting. Your contract should be explicit that you're not warranting code you didn't write. If you fix the checkout and something unrelated breaks two months later, you want that boundary established in writing beforehand.

The rule worth remembering

Charge for the audit. Always.

A free assessment means reading a stranger's codebase for a day and a half for nothing, and it puts pressure on you to recommend the more billable option. Charging a fixed fee makes you independent, gives the client something valuable regardless of what they decide, and filters out the ones who were never going to hire anyone.

---

We audit and take over inherited codebases for US agencies, and we'll tell you honestly when rebuilding is the cheaper answer. See how we work.