If your developer has stopped replying, do this before anything else: confirm you can log into your domain registrar, your code repository, your hosting, and your database. Chasing the person is the natural first instinct and it is the wrong one. The expensive part of a vanished freelancer is almost never the unfinished work. It is discovering three weeks later that the domain renews to their email, the code lives in their personal account, and the production database is behind a login only they have.
Access first. Everything else second.
Separate the Two Problems
There are two things going on, and mixing them up is what turns a bad month into a lost quarter.
Problem one is control. Do you have the keys to the things you paid for? This is urgent and genuinely time sensitive, because accounts lapse, cards on file expire, and free tiers get reclaimed.
Problem two is completion. How does the project actually get finished? This matters enormously but it can wait a week. If you want the framework for that part, it is a separate discipline covered in our guide to projects stuck at 80%.
Work problem one this week. Do not let anyone talk you into scoping a rebuild before you know what you already have.
The First 48 Hours: Inventory Your Access
Go through this list and record, honestly, whether you can log in yourself right now. Not whether you think you can. Actually log in.
The Domain
The single most important item. If the domain is registered under your developer’s account and renews to their email, you can lose your web address entirely while you are still figuring out what happened.
Check who the registrar is and whether the admin email is yours. If the domain is registered to you but managed by them, change the password and remove any additional users.
The Code
Find out where the repository lives. Common situations, roughly in order of how often we see them:
- A repo in the developer’s personal GitHub, GitLab or Bitbucket account, with you as a collaborator or not at all
- A repo in an organization the developer created and owns
- No repository, and the only copy is on their laptop and the server
- A repo you own but have never actually cloned
If you have any level of access, clone it locally today. Access can be revoked. A local copy cannot.
Hosting and Infrastructure
Whatever runs the site or app: the hosting account, the CDN, the serverless platform, the container registry. Check whose payment method is attached. A project running on a developer’s personal card is a project with a countdown on it.
The Database
Databases are where the unrecoverable loss happens. Code can be rewritten. Your users, orders and content cannot. Find where the data lives and get an export of it, even a rough one, even if you do not know what to do with the file yet.
Third Party Services
Payment processing, email sending, authentication, file storage, analytics, SMS, error monitoring, AI APIs. Each one is an account somewhere, often created under the developer’s email with a key pasted into your codebase. Make a list of every service the app talks to and note which ones you can administer.
Design and Content Assets
Figma files, logo source files, stock license receipts, copy documents. Less urgent than infrastructure, easy to forget, annoying to recreate.
What You Own, and What You Might Not
This is worth being clear eyed about, because the answer is often less favorable than people assume.
Whether you own the code usually depends on what your agreement says about intellectual property assignment, and whether the work has been paid for. A plain invoice for services does not automatically transfer copyright in every jurisdiction. Contracts that explicitly assign IP on payment are much stronger ground.
Accounts are a separate question from code. An account created in the developer’s name, under their email, with their payment method, is generally theirs even when the data inside it is yours.
We are a development agency and not a law firm, so treat the above as orientation rather than advice. If real money or a real dispute is involved, spend an hour with an attorney before you send anything adversarial. It is cheap relative to what is at stake.
Reaching Out One Last Time, Properly
Most disappearances are not malice. They are burnout, overcommitment, a health issue, embarrassment about being behind, or a project that went sideways technically and the person could not face saying so. That matters, because a non-adversarial message gets a response far more often than a threatening one.
Send one clear written message. Keep it short, warm, and specific. Ask for exactly these things:
- Transfer of the repository, or a zip of the current code
- A database export
- Ownership transfer of any accounts created for the project
- A list of third party services and what each is used for
- Anything they consider unfinished or broken
Give a reasonable deadline, offer to pay for the handoff time if there is outstanding work, and say plainly that you are not looking for a fight. Put it in writing rather than a phone call, so you have a record either way.
If You Get Nothing Back
You are not starting from zero, even when it feels that way.
If the app is deployed, the front end code is already public, and a developer can read it. If you have any database access, the data model can be reconstructed from the data. Screenshots, a staging link, or even a recorded demo are legitimate specification material.
What is genuinely lost in a total blackout is usually the reasoning: why things were built the way they were, and which parts were deliberate rather than accidental. That is recoverable through reading the code, it just takes time.
The one thing that is truly unrecoverable is data with no export anywhere. Which is why the database is step one, not step four.
Preventing the Next One
Whether you continue with this project or start fresh, change these four things:
- Every account is created by you, in your name, on your card. Add the developer as a user. Never the reverse.
- The repository lives in your organization from day one. Not migrated at the end. The end is exactly when handoffs fail.
- Handoff conditions are written into the agreement. What gets delivered, in what form, and who owns it on payment.
- Payment is tied to things landing in your accounts, not to progress described in a status update.
None of this requires distrust. Good developers expect it and often suggest it themselves. It simply means that if someone vanishes, you lose momentum instead of losing the product.
Where to Go From Here
Once you have your accounts back and a copy of the code, the question becomes what you actually have and what it takes to finish. That answer should come from someone reading the code, not from a quote based on your description of it.
If you are holding a half finished project and are not sure whether it is salvageable, that is exactly the assessment our software project rescue work starts with. You get an honest read on what is there, what is worth keeping, and what finishing it really involves, so your next decision is based on the codebase instead of on how the last one ended.
