You need a developer to take over and finish software that was abandoned, stalled, or built with an AI tool.
If this is not quite your situation, start with the path that matches what you need next.
Have an engineer assess the proposed rescue scope before you commit to another supplier.
Understand the remaining build cost, ongoing costs and assumptions behind the next estimate.
Use capped weekly hours when the project needs steady progress rather than a full-time hire.
Almost every developer who inherits someone else's code will recommend rewriting it. Some of the time that is honest engineering judgement. Much of the time it is because reading unfamiliar code is genuinely harder and less enjoyable than writing new code, and a rewrite is a larger, better-paid contract.
You cannot tell which one you are hearing without an independent look. An audit costs a fraction of a rewrite and takes days rather than months, and it gives you something concrete to hold the next quote against.
In practice a good share of projects declared unsalvageable turn out to need targeted repair — a few broken flows, some missing indexes, a security policy that was never written — rather than demolition.
Before you engage anyone new, make sure the project is actually yours. This is the step people skip, and it is the one that turns a recoverable project into a lost one.
Tools like Lovable, v0, Bolt, Replit and Cursor produce something that looks finished very quickly. The gap is not in the interface — it is underneath: security rules that were never written properly, payment flows that work once but not reliably, and database structures that behave until real numbers of people use them.
The good news is that the output is ordinary code in ordinary frameworks. An experienced engineer can take it over without discarding your interface, so the prototype's speed advantage is preserved rather than wasted.
Expect the first stage to be an audit priced by the day, not by the project. Nobody can quote a completion price for code they have not read, and a fixed price offered before an audit is either padded heavily or about to become a series of change requests.
After the audit you should get a written scope with real milestones. If the person cannot explain in plain language what is wrong and what they intend to do about it, that is the signal to stop, whatever the price.
A rescue engagement should first preserve access, establish what is deployed, and identify the smallest path to a working milestone. Only after that should you decide whether to repair the existing code, replace one part, or plan a larger rebuild.
That sequence keeps a missing developer, an unfinished brief, and a weak technical foundation from being treated as the same problem.
A project rescue is not one generic service. The first useful output depends on what went wrong, and a good engineer should name that output before asking for a completion estimate.
| Situation | First deliverable | Decision after it |
|---|---|---|
| Developer disappeared | Access inventory, deployment map and runnable local setup | Recover, repair or replace the missing handoff |
| AI-generated prototype | Architecture, security and production-readiness audit | Harden the prototype or rebuild one unsafe boundary |
| Unfinished codebase | Working build, feature gap list and dependency map | Finish the smallest launchable milestone |
| Unstable launched product | Incident and data-risk assessment | Stabilise production before adding features |
By the end of the initial rescue phase, you should have evidence rather than reassurance. The engineer should be able to show what runs, what is deployed, what is missing, and which risk blocks the next milestone.
Rescue does not mean preserving every line of inherited code. A rewrite becomes reasonable when the audit shows that the current foundation prevents the required product from being tested, secured or deployed within an acceptable risk and budget.
Even then, the rewrite should be bounded. Keep the working domain knowledge, user flows, data requirements and design assets; replace only the part whose replacement has a measurable benefit. A blanket rewrite before that evidence is not a rescue plan — it is an expensive guess.
Routinely, yes. Taking over an existing codebase is normal senior work. It starts with reading and running the project, not with rewriting it.
Check the repository and hosting accounts first — ownership is often already yours and simply undocumented. If the code genuinely only exists on their machine, what is deployed can usually still be recovered.
A small codebase can be assessed in one to three working days. Larger products need longer when access, deployments, data flows or third-party accounts are undocumented; the audit should state its own scope before work begins.
Yes. A takeover does not require replacing everyone. The incoming engineer can document the system, separate urgent risks from unfinished work, and leave the existing team with a clear milestone plan.
Start with a capped audit and require a written list of assets, defects, assumptions and milestones. Do not approve a fixed completion quote that was written before anyone ran or inspected the existing code.
