aaron8.
  1. Home
  2. Project rescues

I'm usually the second developer.

The first one vanished, or the agency went quiet, or the AI-built app does everything except the one thing you bought it for. Most of my career has been walking into things mid-flight, and the first job is always the same: work out what the last person meant, then say plainly what it will take to finish.

Live proof

What a rescue leaves you with.

The inherited mess on one side, the finished site on the other. Flip between them, then read the ownership panel: every domain, host and account back in your name, documented, with nobody else holding the keys.

live demoA rescued project, before and after

This working build runs in your browser and needs scripts enabled. Everything on the page describes what it does; turn them on to use it.

A rescue ends with you owning everything and the thing actually finished. Not a report about what went wrong.

The method

Stabilise, read, then finish.

  1. Get you holding your own keys. Domain, hosting, repository, database, email. A worrying number of rescues start with the discovery that the business owns none of its own property. That gets fixed first.
  2. Find out where it really stands. Not where the last invoice said. What is built, what works, what is scaffolding pretending to be a building. You get this in writing, in plain words.
  3. Agree what finished means. Often smaller than the original dream and sooner than you fear. The original scope died with the original plan; the job now is the shortest honest path to something running.
  4. Finish it, and prove it. Working software, tested, documented and in your hands, with the evidence that it does what we agreed, not my assurance that it does.

The new rescue

"We built it with AI and it almost works."

I review AI-built systems, and they fail in patterns. On one live shopping platform I was asked to check before customers were put on it, I proved six gaps by using them, then re-tested after the fixes: four properly closed, two not, and I said so. The same review cleared one reported problem as a phantom, which saved a week of chasing.

  • A new secure login, and the old insecure way in still open beside it. I logged into another account and shut down their live broadcast to make the point undeniable.
  • A performance check that could only ever pass, scoring blanks against blanks, recorded in the project notes as verified.
  • Deleting an account deleted its paid invoices while telling the customer the records were kept. For a business facing tax time, a liability, not a bug.

Fair questions

Before you ask.

My developer disappeared. What do I do first?
Secure what you own before anything else: domain registrar, hosting, code repository, database, email sending. Then get an independent read on where the project actually stands, because "nearly done" from the last person and reality are often strangers. That read is the first thing I do on a rescue.
Will you rubbish the last developer?
No. Most half-finished projects come from scope drift, thin budgets or a relationship failing, not incompetence, and trashing the last person tells you nothing about the code. You get a plain statement of what is there, what works, and what it takes to finish.
Is it cheaper to finish it or start again?
The assessment answers exactly that, with reasons. Sometimes the half-built thing is a foundation; sometimes it is a hole. I have recommended both, and the recommendation comes before you commit to the bigger spend, not after.
Can you work with the previous developer still involved?
Yes, and it often goes better than owners expect. A second pair of senior eyes with no ego in the original decisions can unblock a project without anyone losing face. I have spent a career being that person inside big organisations.