Can you take over a project another developer started?

Yes. Inherited codebases are their own discipline: the work starts with an audit that establishes what is really there, then stabilisation, then the remaining scope as a plan with dates. Access to the repository, the hosting accounts and any documentation that exists is all that is needed to begin.

Should we fix the existing code or start over?

Usually fix it. A rewrite looks cleaner because the existing code's problems are visible and the new code's are not yet, and it throws away every business rule the original team encoded but never documented. A rewrite is the right call when the stack is genuinely unsupportable or the data model cannot represent what the business now does — the audit is what tells you which case you are in.

What do I get from the audit if we do not continue?

The written report, and it is yours. It states what the codebase does, how complete it is, what the risks are and what completing it would involve — which is exactly what you need to brief whoever takes it on next, whether that is me or someone else.

Rescue a failed software development projectService — Project Rescue

An honest read on what you actually have, what it would take to finish it, and whether finishing it is the right call — before you spend anything else on it.

Signs a project is in trouble

The pattern is consistent, and recognising it early is worth more than any single fix.

Every estimate slips, and nobody can say precisely why
The previous developer has gone quiet, or has already left
Nobody can deploy it except one person
There is no documentation and no test suite to substitute for one
New features keep breaking features that used to work
You are being told a rewrite is the only option, by the people who would do the rewrite

The code audit

The first step is a read of what exists, ending in a written report you own regardless of whether we work together afterwards. It covers what the codebase actually does versus what it was supposed to do, how far along it genuinely is, where the structural problems are, what the security and dependency position looks like, and what it would take to get it to a releasable state. The report is written to be understood by a non-technical founder and checkable by a technical one.

Stabilise first, then decide

Nothing gets rewritten before it is understood. Stabilisation comes first — get it building reliably, get it deploying reliably, get the worst breakages contained — because a system nobody can deploy cannot be evaluated honestly. Only then is refactor-versus-rewrite a real decision, and it is usually refactor: a rewrite discards every undocumented business rule the original team encoded, and those rules are the part nobody wrote down.

Taking over an unfinished build

Taking over means becoming the person who can answer questions about the codebase — reading it properly, documenting the parts that were never documented, putting tests around the areas that keep breaking, and getting the deployment pipeline into a state where releases are boring. From there the remaining scope gets rebuilt as a plan with dates attached rather than an open-ended commitment.

Keeping it healthy afterwards

Most rescued projects failed partly because nobody owned them between releases. Ongoing maintenance — dependency and security updates, performance work, bug fixes and small features — is available as continuing work once the project is stable, so it does not drift back into the same position.

Where I’ve done this

Shipped projects that use the work described above.

Common questions

Can you take over a project another developer started?: Yes. Inherited codebases are their own discipline: the work starts with an audit that establishes what is really there, then stabilisation, then the remaining scope as a plan with dates. Access to the repository, the hosting accounts and any documentation that exists is all that is needed to begin.
Should we fix the existing code or start over?: Usually fix it. A rewrite looks cleaner because the existing code's problems are visible and the new code's are not yet, and it throws away every business rule the original team encoded but never documented. A rewrite is the right call when the stack is genuinely unsupportable or the data model cannot represent what the business now does — the audit is what tells you which case you are in.
What do I get from the audit if we do not continue?: The written report, and it is yours. It states what the codebase does, how complete it is, what the risks are and what completing it would involve — which is exactly what you need to brief whoever takes it on next, whether that is me or someone else.