My Developer Disappeared Mid-Project: How to Recover Your App or Website

You paid a deposit, sometimes the full amount. You had calls, maybe a signed statement of work. Then the replies got shorter, the “almost done” updates stopped matching the staging environment, and at some point the emails stopped coming back entirely.

What you’re facing has a name in the software industry: a software project rescue. It happens often enough that agencies run a standard process for it.

Quick answer: Rotate every credential the old developer had, confirm exactly what code and infrastructure access you control, and get a short paid code audit before hiring anyone new. Don’t sign a new contract until you know whether the existing work is worth keeping. Most projects with intact source code and infrastructure access are recoverable within weeks; the real losses happen when nobody checks access and ownership until months later.

Key takeaways

• Access decides the outcome. Recoverable source code, hosting, domain, and database access makes a project fixable in weeks.
• Ownership isn’t automatic. A contractor keeps copyright over their code unless a signed agreement assigned it to you.
• A short audit beats a guess. A few paid hours of review costs far less than an unnecessary rebuild.
• This has an industry name. Software project rescue, also called IT project rescue, is a standard service line, not a favor.
• AI tools help you triage, not replace, a real audit. More on exactly where, below.

Why developers vanish mid-project

The freelance software market is large: roughly a third of all freelance work globally is web, mobile, or software development, and the U.S. independent workforce alone runs into the tens of millions. At that scale, some engagements collapse.

Recurring causes:

• Underpriced scope. A fixed quote balloons to three times the real work once requirements surface.
• Overbooked freelancers. A solo developer rarely turns down new work, so your project slides to the back of the queue.
• Life circumstances. Illness, a new job, a family emergency. Not every disappearance is bad faith.
• Repeat offenders. Some collect a deposit, request “delivery acceptance,” then vanish, often with the same pattern visible in public reviews elsewhere, one of several recurring problems that quietly derail software projects.

Long-running industry research on software delivery outcomes still finds only a minority of projects finish exactly on time, on budget, and on scope, even with fully staffed teams. A stalled solo build isn’t a freak failure. It’s a known, quantified risk of how this work gets contracted.

The first 48 hours: what to do immediately

Resist the urge to post a new job listing right away. Work through this first, in order.

1. Rotate every credential the old developer touched. Hosting, domain registrar, database, and API keys, even if things ended fine.
2. Pull a full backup of everything you can reach. Database, codebase, and design files, stored outside the original accounts.
3. Write down what you actually know. What was scoped, what works, what’s paid. Memory fades fast.
4. Escalate through the platform’s dispute process if support goes quiet. A factual public review often gets a response private messages couldn’t.
5. Get a short paid code audit before committing further. Developers call this a “rescue audit,” and it beats another sales call.
6. Try an AI assistant for a first-pass onboarding summary before paying for a deeper audit. More on where AI tools help, and where they don’t.

Don’t sign anything new until you’ve read the ownership section below. A developer eager to start with zero questions about existing IP is a warning sign.

The recovery readiness checklist

Before contacting a new developer, spend thirty minutes confirming what you have. This decides the cost, timeline, and whether “recovery” or “rebuild” is the right word.

Asset	What to check	Why it matters
Source code repository	Owner-level repository access, full history, not just a final zip	History shows real progress and design decisions
Hosting or cloud account	Deployed under an account you control	Otherwise the app can vanish the moment access lapses
Domain registrar	You personally hold the login	Losing domain control can take weeks to reverse
Database and backups	You can export data now, and know the last backup date	No accessible backup means one hiccup from total loss
API keys and subscriptions	Stripe, SendGrid, Firebase, whose account bills these	Overlooked until a payment fails and the app breaks
Design files	Figma or XD files in an account you control	Otherwise a new team reverse-engineers the UI
Written contract	A signed agreement covering deliverables and IP	The single biggest factor in what happens next

Missing two or fewer usually means a straightforward recovery. Missing the repository, hosting, and contract puts you in a much harder spot, and confirming your infrastructure setup is worth doing early.

The security audit almost nobody runs after a developer disappears

Every guide on this topic covers access and ownership. Almost none cover what happens afterward.

Credential rotation isn’t the same as closing every door. API keys and tokens a departing developer generated keep working even after their login is disabled: GitHub, GitLab, and cloud IAM tokens rarely expire on their own.

Before a new developer touches anything, check:

• Every API key and access token the old developer generated, not just their main login
• OAuth apps or third-party integrations authorized under their account
• Admin accounts still active on the database, hosting panel, or CMS
• DNS records and SSL certificates, confirming nothing routes through an account you don’t control

Thirty to ninety days of post-departure monitoring catches anything missed. This is exactly what a proper pre-launch security review is built to catch.

Who actually owns the code right now?

This is the step people skip, and it causes the most expensive mistakes later.

Under copyright law in most countries, including the US per the U.S. Copyright Office’s guidance, the person who wrote the code owns it by default, even if you paid for it. That changes only if the contract properly qualified as “work made for hire,” or included a clause assigning copyright to you on payment.

Paying an invoice alone doesn’t transfer ownership. The first question for any new developer shouldn’t be about timeline. It should be about who owns the existing code.

With a proper assignment clause, a new developer or team can pick up the work directly. Without one, many original developers will sign a short release once they’ve moved on.

A less common option: a small buyout for signed rights, often faster than a legal dispute. If neither works, a new developer can treat the code as reference while writing fresh implementation, which sidesteps ownership but adds time. This isn’t a substitute for legal advice.

Is it recoverable, or should you start over?

This is the technical decision, separate from the legal one. A senior developer weighs a consistent set of signals.

1. Signs the codebase is worth continuing

• Logical file structure with sensible naming and some documentation
• A current framework with dependencies still receiving updates
• Some automated tests, even a handful
• Core features that function end to end, even if rough
• Clean, documented ownership with no gap in who holds the rights

2. Signs you should rebuild instead

• Everything crammed into a handful of undocumented files
• A deprecated framework, or dependencies with known security holes
• Zero tests, so every change is a gamble
• Mostly scaffolding with little real functionality underneath

The strongest argument for a full rewrite is rarely code quality. It’s unprovable IP provenance, since a missing rights transfer from any contributor follows you into a future funding round.

Reaching real fluency in an undocumented inherited codebase realistically takes three to six months, even in a best-case handoff. That’s why a realistic timeline built on an actual assessment beats a guess made on the first call.

Can AI coding tools help you assess or recover the project yourself?

AI tools are a genuinely new option here, and they deserve an honest answer, not hype or dismissal.

1. Where they help

• A coding agent can produce a written onboarding summary (architecture, bugs, deployment steps) as a cheap first pass
• Agentic tool session transcripts sometimes persist locally and can be searched for code that never got committed
• Browser-based AI builders sometimes store generated files in a linked cloud storage bucket, worth checking before assuming nothing survived

2. Where they fall short

• The same tools that deliver roughly 35 to 40 percent productivity gains on clean, greenfield tasks often manage 10 percent or less on a legacy codebase, a fourfold gap driven by comprehension, not raw coding skill
• Most models reason at the function level, not the system level, a real limit when a flawed decision from year one got copied across every module
• Sessions without real version history have silently deleted working files mid-session; use a tool that syncs to your own disk

The honest summary: AI tools are a legitimate triage step for small codebases. For anything large or handling real user data, they’re a starting point for a proper human QA pass, not a replacement, and the full comparison covers this in more depth.

What a structured software project rescue actually involves

Once you know what you have, a rescue engagement runs through four stages worth knowing before you hire anyone.

1. Assessment. Audit the codebase, infrastructure, and documentation to establish what’s built, broken, and hidden underneath.
2. Strategy. A concrete plan: what’s kept, what’s rewritten, the sequence, and where the risks sit.
3. Execution. Development resumes in short, visible increments, not one long silent stretch.
4. Delivery. The product goes live with testing and a documented handoff.

This mirrors how GVM Technologies runs its own project rescue engagements. A common pattern: a founder pays a deposit, the freelancer collects the balance and disappears, and the project turns out to be sixty percent finished with no documentation.

The fix is rarely a full rewrite. It’s usually a two-to-three-week stabilization pass that finishes what already exists.

DIY, hire another freelancer, or bring in an agency

There’s no single right answer. It depends on your technical judgment and how much is riding on getting this right.

1. Finishing it yourself with AI tools (vibe coding)

Workable for a low-stakes personal project with no deadline pressure. Riskier once real users, payments, or sensitive data are involved.

2. Hiring another individual freelancer

Fastest and cheapest for small, well-scoped work, with the same single-point-of-failure risk that got you here. Insist on a real contract, and compare the full cost picture first.

3. Bringing in an agency or rescue specialist

The stronger option for anything customer-facing or handling payments and user data. Higher upfront cost, but a team instead of one point of failure. Dedicated resources are worth comparing against a single hire if you need ongoing capacity.

Whichever route you take, insist on milestone payments tied to working demos, a repository under your own organization’s account, and ownership language in writing before code gets written.

What this actually costs and how long it takes

There’s no honest single number, and any provider who quotes one before seeing your codebase is guessing. Cost and timeline depend almost entirely on the assessment findings above, plus how much of the existing work is salvageable.

1. Light rescue

Working product with a handful of bugs. Usually weeks, not months, once a new team is up to speed.

2. Moderate rescue

Real refactoring and some rebuilt features. Industry-wide ranges put this at 40 to 70 percent of the original budget, plus a few extra weeks.

3. Near-total rebuild

Code too poor to build on safely. Approaches the cost of starting fresh, minus the design work already done.

The assessment phase exists to replace this range with an actual number for your project. A realistic sense of overall development costs is useful context while you decide.

Preventing this the next time you hire a developer

A few habits make a repeat far less likely.

• Pay in milestones tied to working demos, never one large deposit up front
• Put IP assignment in writing before a single line of code gets written
• Keep the repository under your own organization’s account from the first commit
• Watch for a developer who reroutes you into paying a third-party bill directly before delivery
• Watch for someone insisting on building everything from scratch for their own learning, not your timeline
• Watch for a collaborator active elsewhere while going fully quiet on your threads specifically

Don’t skip QA on the assumption you’ll catch problems later. What tends to go wrong when startups skip QA testing covers this in more depth. And if the codebase is aging even with the same developer involved, that’s a modernization conversation, not a rescue one.

FAQs

1. Can I use the code my old developer wrote without a signed contract?

It’s a legal gray area without a written release or assignment clause. The safer path is a short written release, or treating the code as reference while writing fresh implementation.

2. Is it worth suing a developer who disappeared?

Rarely, for most small budgets, since litigation often costs more than it recovers. Securing access and documenting what happened is usually more productive.

3. How do I know if a new developer or agency is trustworthy?

Ask about their process for taking over an existing codebase. A credible answer includes an audit before a quote.

4. What if I don’t have the source code at all?

Not ideal, but not fatal. A live site can sometimes be reconstructed from what’s publicly viewable, and a CMS database often holds more structure than expected.

5. Should I pay the remaining balance to get the original developer to finish?

Only with a concrete, time-bound plan and payment released against specific milestones. If they’ve gone quiet for weeks, more money rarely restarts the work.

6. What’s the single biggest mistake people make after a developer disappears?

Hiring a replacement before securing access and ownership. A second developer billing hours against an unassessed codebase forces decisions a thirty-minute access check would have prevented.

Getting your project back on track

A stalled project feels like a dead end, but it rarely is one. It’s an access problem, an ownership question, and a technical assessment, worked through in that order.

If you’d rather have someone experienced run that assessment, GVM Technologies’ project rescue team starts with the audit process described above, before any quote or timeline gets promised.

Book a meeting to walk through what you have. No obligation.