Your freelancer vanished: what to do now

Your messages go unanswered. The phone rings out. The site stopped updating and you don't even know where it's hosted. Whoever was building your project vanished, and with them went the passwords, the code and the only person who knew how things worked.

It doesn't only happen with freelancers. In May 2025, Builder.ai, a London company once valued at US$1.5 billion with more than 500 employees, announced at an internal meeting that the money had run out, according to Rest of World's investigation. In June, its site went offline. A solo developer or a big company, the risk is the same: your product depends on accounts that aren't in your name. In this guide I show the right order for getting out of this situation.

First: delete nothing and gather evidence

Before doing anything, save everything that shows the project is yours. You'll need it to recover access and, if it comes to that, to talk to a lawyer.

• Contract, proposal and scope, even if they were exchanged by email or WhatsApp.
• Payment receipts and invoices.
• Conversations where the vendor talks about the project, the accounts and the deliverables.
• Links, screenshots and any access you still have, even as a guest.

Make a copy of everything off your phone. Don't send angry messages or threats. A clear, written message asking for access and setting a deadline is worth more and serves as a record.

Recover access, in this order

What holds your product up is the accounts. Start with the ones that would stop everything if lost.

1. Domain. It's your site's address and often your email's too. For .br domains, look up the owner on Registro.br. If the domain is under your company's CNPJ but you no longer have access to the account that manages it, Registro.br has a procedure called Owner Contact Transfer, done by submitting documents and reviewed in 2 business days. If the domain is under the vendor's CPF or CNPJ, changing ownership requires their signature.
2. Hosting and cloud. Find out where the site or system runs and whose name the billing is under. If the account is charged to the vendor's card and expires, the product goes offline without warning.
3. Code. The repository (GitHub, GitLab or Bitbucket) needs to be in a company account. On GitHub, an admin can transfer the repository while keeping history, issues and pull requests. For a personal account, the invitation expires in 1 day if not accepted.
4. Database and backups. This is your customers' data. Find out where it lives, who has access and when the last backup was made.
5. App store accounts. At Apple, an app transfer is started by the current account's Account Holder, and the app keeps its reviews, ratings and Bundle ID. On Google Play, the original account owner requests the transfer, support responds within 2 business days, and users, stats, reviews and subscriptions carry over. In both cases, whoever holds the account has to start it.
6. Services tied to the product. Transactional email, payment gateway, analytics tools, API keys. Change passwords and keys as soon as you recover each one.

If the vendor won't respond and the accounts are in their name, you'll depend on their cooperation or on a legal route. This is where it's worth talking to a lawyer.

What's yours, by law

In Brazil, Law 9,609/1998, the Software Law, treats software as a work protected by copyright. Two points matter to whoever hired the work:

• The client holds the rights, unless the contract says otherwise. Article 4 says the rights to software developed during a service contract belong to the client. If your contract says something else, the contract prevails.
• Protection doesn't depend on registration. Article 2 guarantees protection for 50 years and says it doesn't require registration.

In practice, this helps you negotiate the handover of the code. But the law won't recover a password. If the vendor refuses to hand over what was paid for, every case has its details, and a lawyer should assess it.

Also make a simple written list of what you have and what's missing. For each item (domain, hosting, code repository, database, app store accounts and design files), note whose name it's in and whether you have owner access, guest access or none.

That list is the starting point for any team that takes over the project.

Assess the state of the code

Once you have access, someone needs to look at the code, not just the screens. The freelancer may have left something nearly done or something that only looks done. A good assessment answers:

• Does the product run outside the developer's machine?
• Do the main flows work end to end, with real data?
• Is there basic documentation on how to install and deploy?
• Are there passwords and keys lying around in the code?
• Can another team understand and work on what was built?
• Does the technology used still get updates?

The result is a list of what stays, what gets fixed and what gets rebuilt. Without that list, any new quote is a guess.

Continue or rebuild

Continuing makes sense when the database is well modeled, the main flows work and another team can maintain the code. Rebuilding makes sense when every fix breaks something else, when you can't deploy without fear or when fixing security means touching almost everything.

Often the answer is mixed. You can keep the data, the design and the business rules and rewrite only the parts that hold things up. If your project didn't vanish but isn't moving, the guide on delayed software projects shows how to decide while the vendor is still around.

How to keep it from happening again

I've seen this pattern for over ten years. The problem is almost never just the person who vanished. It's that everything was in their name. Next time you hire:

• Accounts in the company's name from day one. Domain under the company's CNPJ, hosting on the company card, repository in an organization you own, app store accounts in your name. The vendor comes in as a guest.
• A written contract. Scope, deadline, and a clear clause that code, files and access belong to the company.
• Passwords in a company vault. Never only in a WhatsApp chat.
• Deliverables you can see. The product running in a test environment, not just screenshots.
• More than one person who knows the project. A project that depends on one person stops when that person stops.

How we do it at the Studio

At the Studio, a rescue starts with access and a read of the code. We help map whose name each account is in, test the main flows and list what stays, what gets fixed and what gets rebuilt. That list becomes a fixed price, and the deadline is written into the contract.

Code, files and access stay in the client's name, always. The dev team is the Studio's own, so the project doesn't depend on a single person. And every system ships with an AI agent that runs daily, flags failures, suggests improvements and checks that the data makes sense.

If whoever was building your project disappeared and you want to recover what you already paid for, the Studio's project rescue starts with those accesses.