Our Developer Disappeared After Launch: Now What?

When your developer disappears after launch in the Philippines, the panic arrives fast. The website is live, customers are using it, and the person who built it has gone dark. Calls go unanswered, messages sit on read, and that small fix you needed two weeks ago is still broken.

This is more common than it should be, and there is a clear path through it.

When Your Developer Disappears After Launch: Stop the Bleeding First

Before anything else, triage what you actually have access to.

Check every account that touches your product: domain registrar (GoDaddy, Namecheap, or similar), web hosting or cloud provider (DigitalOcean, Vercel, AWS), DNS settings, the database, and any third-party integrations like payment gateways or email services.

If your developer registered these accounts under their name, your business is technically running on infrastructure you do not control. That is the most urgent problem. Most platforms have account recovery processes when you can prove business ownership - start those requests immediately.

If you already have access to the accounts: change every password and move billing to a card your company controls. Do not wait.

Taking Back Code and IP That Should Be Yours

Code ownership is where things get complicated. In the Philippines, if you paid for custom development and had no written agreement, the IP can default to the developer - even if you paid them for the work. This surprises founders every time.

What you can do right now:

• If the code is on a GitHub or GitLab repo and you have access, download everything and fork it to an account you own. Do not rely on a shared link staying live.
• If you only have a running app and no source code, a developer can often reconstruct the structure from the deployed version. It is not clean, but it gives you something workable.
• If a contract exists, read what it says about IP assignment. If it states the developer retains ownership until final payment and you are in a dispute, get legal advice before acting.

The goal is not to punish anyone. It is to get your business back on solid footing.

Audit Before You Pay Anyone New

The second most common mistake is hiring the first developer willing to take the job and paying them to fix things without understanding what is actually broken.

Before you bring anyone in, commission a technical audit. This does not have to be expensive. A competent developer spending three to four hours reviewing your codebase and infrastructure can tell you: what is broken and why, what the technical debt load looks like, whether the existing code is worth patching or whether rebuilding on a stable foundation makes more sense, and what realistic ongoing maintenance costs look like.

An audit is cheap insurance against paying to repair a foundation that cannot hold. For projects where the original build was done hastily, "fix my broken website" sometimes turns out to mean "start over with proper structure" - knowing that early saves money and months of frustration.

Do not commit to a full rebuild without the audit. But do not commit to patch-only either.

Questions to Ask Any New Developer or Studio

When someone ghosted you, repeating the pattern with the next hire is the thing to avoid. Before signing anything:

• Who owns the code and IP at the end of the engagement? Get this in writing, not just verbally.
• Where does source code live, and will you have admin access throughout the project?
• How is ongoing maintenance handled and what are the response time commitments?
• What documentation is delivered when the project closes out?

A developer or studio uncomfortable with any of these questions is signaling something. Discomfort here is not a negotiating tactic on their part - it is a real answer.

For larger or mission-critical projects, working with a registered studio rather than a solo freelancer adds a layer of accountability. There is a business entity behind the work, not just a contact saved in WhatsApp.

What Recovery Actually Costs

Recovery engagements vary based on what the original developer left behind. A system with clean, documented code and proper access handover is far cheaper to take over than one with zero documentation, locked accounts, and a database nobody can log into.

What drives cost up: whether source code exists and is accessible, how much technical debt accumulated during the original build, whether infrastructure is documented or has to be reconstructed from investigation, and whether customer data needs to be migrated or recovered.

Every project is scoped individually because the conditions differ every time. Some recoveries are a few days of work. Others run for weeks. The audit step exists precisely to answer the cost question before anyone commits.

How to Avoid This Happening Again

Once you are back on stable ground, a few practices make it much harder to land here a second time.

Require source code access from day one - not after launch, not after final payment. From the first sprint. Run your domain and hosting accounts in your business name, with billing on a company card. Have a written agreement that assigns IP to your company upon payment; this is standard practice and any legitimate developer accepts it.

Ask for documentation as a deliverable, not an afterthought. And agree on who provides post-launch support before you sign the contract, not the week something breaks in production.

Developers who disappear are not always acting in bad faith. Sometimes they get overwhelmed, take on too much, or face their own crises. But the consequences land entirely on your business. Good process protects you regardless of what happens on the other side.

---

If your developer has gone dark and you need someone to take over, audit what was built, or fix what is broken, we can help. Every engagement starts with a scoping conversation so you know exactly what you are walking into.

Start a project →