First, before anything technical

Secure your assets. Repository, domain registrar, hosting, cloud accounts. Do this before raising a dispute, changing tone, or announcing a decision. Access becomes considerably harder to obtain once a relationship turns adversarial.

Projects stall. Most are recoverable. What determines the outcome is what you do in the first week — and it is rarely what people instinctively do.

Week one: contain

  1. Get repository access if you do not have it. Frame it as standard practice, not as an accusation. This is the single most important step.
  2. Verify account ownership — domain registrar, hosting, cloud, third-party services. Transfer anything in the vendor's name.
  3. Take a full backup of code, database and configuration.
  4. Document the current state — what runs, what does not, what you were told.
  5. Stop adding scope entirely.
  6. Keep the relationship civil. You may need cooperation for handover, and antagonism costs you that.

The order matters. Clients frequently confront the vendor first and then discover they cannot access their own domain. Secure everything you are entitled to while the relationship is merely disappointing rather than adversarial — it is not deceptive, it is prudent.

Week two: assess honestly

Three questions, in order:

1. What actually exists?

  • Can the code be built and run from a clean checkout?
  • Which features work, which are partial, which were never started?
  • Does the database contain real structure or placeholder data?
  • Is there anything deployed anywhere?

2. Is it worth keeping?

  • Is the architecture coherent, or was it assembled without a plan?
  • Are there tests, or any safety net at all?
  • Is the technology supportable and hireable-for?
  • Are there security problems that cannot be remediated in place?

3. What would it cost to finish versus restart?

The comparison people get wrong, because restarting always feels cleaner and is usually not.

A failed project is usually a failure of scope, communication or completion — not of code quality throughout. Substantial parts are frequently sound, and discarding them discards paid-for work.

The decision

SituationUsual answer
Mostly built, some parts brokenFinish it
Sound architecture, incomplete featuresFinish it
Works but unmaintainableStabilise, then refactor incrementally
Unsupported technology stackRebuild, reusing the domain logic
Fundamental security problemsRebuild the affected layer
Very little actually existsRestart with proper scoping

The most common correct answer is "stabilise, then finish". Get it deployable, add tests around the critical paths, fix the security issues, then complete the remaining features. It is less satisfying than a clean rebuild and it is usually months faster.

Stabilising before building

Whatever the decision, do these first:

  1. Make it deployable — a repeatable process anyone can follow.
  2. Rotate every credential. Assume the previous team retains access.
  3. Add monitoring so you know when something breaks.
  4. Verify backups work by restoring one.
  5. Add tests around the critical paths before changing them.
  6. Fix immediate security exposure.

Why the project failed, and not repeating it

Before restarting work, establish the cause honestly — including your own contribution:

CausePrevention next time
Scope was never written downWritten scope with exclusions, signed
No visibility into progressWeekly demos of working software
No code access until the endYour repository from day one
Scope grew without schedule changeWritten change process
Vendor lacked the capabilityAsk what they have not done
Too many decision-makersOne named owner
Paid fully up frontMilestone payments

Several of these are client-side. A rescue that changes only the vendor frequently produces a second rescue.

Choosing who takes it over

  • Ask for an audit before a build quote. Anyone quoting to finish without reading the code is guessing.
  • Be suspicious of immediate rebuild recommendations. Rebuilding is easier to quote and more profitable; it is not always right.
  • Ask what they would keep — a specific answer indicates they actually looked.
  • Start with a small stabilisation piece before committing to completion.
  • Insist on the controls that were missing last time.

On recovering money

Understandable instinct, usually a poor use of energy. Cross-border litigation is slow and expensive, and it does not produce working software. If a settlement is achievable through negotiation, take it — otherwise put the energy into the project. The cost of the delay usually exceeds the fees in dispute.

Have a project that has stalled? Tell us where it stands — we audit before quoting, and we will say plainly if the code is worth keeping. See our how to audit an inherited codebase and why projects fail.

Frequently asked questions

Rarely worth it, particularly across jurisdictions. Litigation is slow, expensive and does not produce working software. Energy spent securing assets and getting the project moving usually returns more than energy spent on recovery of fees.
More than clients expect — frequently 40–70%. Failed projects are usually failures of scope, communication or completion rather than of code quality throughout. Some parts are typically sound and worth keeping.
Assessment takes one to two weeks. If the code is workable, meaningful progress within a month is realistic. The delay is almost always in getting access and establishing what actually exists, not in the engineering.