Your developer stopped replying. Messages go unread. The last commit was three weeks ago and the demo they promised never showed up. If you're sitting there thinking "my developer disappeared, what do I do now," take a breath. This happens more than anyone admits, and it is recoverable more often than you'd think. I've been the person who gets called in to clean up after a developer ghosted a startup founder, and there is a clear order of operations. Let me walk you through it.
The first 24 hours: stay calm and secure what you can
The instinct is to panic or to fire off angry messages. Don't. Angry messages give a disgruntled developer a reason to lock you out or delete things out of spite. Stay professional, even if you're furious.
Your first job is not to fix anything. It's to secure access to everything you can still reach. Make a list right now of every account and service connected to your project. That means email, code hosting, the server or hosting provider, the domain registrar, any database, payment processors, and third-party tools like email senders or analytics.
For anything you can log into, do two things: change the password, and check who else has access. Remove the developer where you can safely do so without breaking the running app. Be careful here. Yanking access to a live production server can take your app offline if you don't know what's connected to what. If the app is live and customers are using it, leave the running services alone for now and just secure the accounts you control.
Send one calm, documented message: "I haven't heard from you since [date]. I need the current code and access credentials by [date]. Please confirm." Keep it in writing. You may need this trail later.
Getting access: GitHub, servers, domains, and accounts you may not know exist
Here is where most non-technical founders get stuck. Your code and your project live across several accounts, and you may not even know they exist. Let me name them so you can hunt them down.
- Code hosting — usually GitHub, sometimes GitLab or Bitbucket. This is where the actual source code lives. If the repository is under the developer's personal account instead of yours, that is a problem you need to solve first.
- Hosting / servers — AWS, Google Cloud, DigitalOcean, Vercel, Render, Heroku. This is where the app actually runs.
- Domain registrar — GoDaddy, Namecheap, Cloudflare. This controls your web address and email.
- Database — sometimes bundled with hosting, sometimes a separate service like Supabase, MongoDB Atlas, or PlanetScale. This holds your actual user data.
- Everything else — Stripe, SendGrid, Twilio, OpenAI, error trackers. Each one has a login and often a bill.
Check your email and your credit card statements. Every paid service sends receipts and every signup sends a welcome email. Search your inbox for "welcome," "receipt," "invoice," and "verify." Your card statement will reveal subscriptions you didn't know you were paying for. Those charges point straight to the accounts you need.
If a critical account is registered under the developer's email and you can't get in, use the provider's "account recovery" or "account ownership dispute" process. Many providers will transfer ownership if you can prove you paid the bills. This is slow but it works. This whole mess is exactly why I tell founders that everything should be in your name from day one.
How to assess the damage without being technical
Say you get the code back. Now what? You can't read it, and you don't know if it's a nearly finished product or a pile of half-working files. This is where a code audit comes in.
A code audit is when an experienced developer reviews the codebase and gives you a plain-English report: what's built, what works, what's broken, how it's structured, and how much of it is salvageable. A good audit answers the questions you actually care about:
- How much of what I paid for is actually done?
- Is the code reasonable quality, or is it held together with duct tape?
- Can a new developer pick this up, or would they spend more time understanding it than rebuilding it?
- Are there security holes or data risks I need to fix immediately?
Expect to pay for a few hours of a senior developer's time. It's worth it. The audit stops you from throwing good money after bad, and it stops the next developer from telling you "it's all garbage, let me rebuild from scratch" when that may not be true. That claim is sometimes honest and sometimes a sales tactic. An independent audit tells you which.
Be aware of one common failure mode. If the previous developer leaned heavily on AI to generate code without understanding it, you can get something that demos well but falls apart in production. I've written about exactly why AI-built MVPs fail in production, and a good audit will flag those cracks.
Can you recover the project, or should you rebuild?
This is the big decision, and the honest answer is: it depends, and here's what it depends on.
Recover makes sense when the audit shows the core structure is sound, most of the work is genuinely done, and the code is readable enough for a new developer to continue. If you're 60% of the way to launch on a solid foundation, throwing that away is expensive and pointless.
Rebuild makes sense when the audit finds the code is a mess, poorly structured, or so thin that there's barely anything there. Sometimes the "finished" work is a login screen and three empty pages. In that case, a rebuild on a clean foundation is faster and cheaper than untangling someone else's shortcuts.
There's a middle path most people miss: keep the parts that work, rebuild the parts that don't. A skilled developer can often salvage the database and the well-built features while replacing the broken ones. This is usually the smartest option after a ghosting, because it respects the money you already spent without inheriting all the debt.
Whatever you decide, don't rush the next hire based on how burned you feel. Read up on the real trade-offs between a solo developer, an agency, and AI tools before you commit again. The right choice depends on your budget and how much hand-holding you need.
Handling payments, contracts, and IP disputes
If you paid for work you didn't get, you have some options, but manage your expectations. Chasing a freelancer through the courts is usually more expensive than the money you're trying to recover, especially across borders.
Practical steps that actually help:
- Stop future payments. If there's a retainer or subscription, cancel it. If you paid through a platform like Upwork or Toptal, open a dispute through them. Platforms have mediation processes and they work.
- Check who owns the IP. Your contract should say the code and everything produced belongs to you on payment. If it does, you have a right to the code. If you never had a contract, this is a hard lesson. Get one next time.
- Document everything. Save the messages, the invoices, the dates. If you paid by card and got nothing, a chargeback is sometimes possible for recent payments.
The truth is most founders don't recover the money. What they do recover is control of their accounts and their code, and that matters far more for actually shipping the product.
How to never end up here again
The ghosting hurts, but the setup that made it a disaster was in place before the developer disappeared. Fix that, and next time a bad hire is an annoyance instead of a catastrophe.
- Own every account from day one. GitHub, hosting, domain, database, every third-party tool. Create them under your email and add the developer as a collaborator. When they leave, you remove them in thirty seconds.
- Pay by milestones, not lump sums. Break the project into chunks and pay when each chunk is delivered and demonstrated working. You should never be more than one milestone ahead of what you've actually received.
- Get working demos, not status updates. "It's going well" means nothing. A live link you can click means everything. If a developer can never show you running software, that's your early warning.
- Have a written spec. A clear spec is your protection. It defines what "done" means so no one can claim vague progress. I wrote a whole guide on the spec that survives a developer for exactly this reason.
Do these four things and you're never fully at anyone's mercy again. It's the same discipline I use in my own eight-week build process: the founder holds the keys the entire time.
If you're staring at a ghosted project right now and you don't know whether it's recoverable, send me the details. I'll tell you honestly whether it's worth saving or whether you're better off rebuilding, and I won't pretend it's a rescue job if it isn't.
