What to Do When Your Software Developer Disappears

When a software developer stops responding, the first job is not to rewrite the system. Protect the live service, preserve code and data, identify who controls every account, document the last known working state, and create a safe path for a replacement to assess it.

Act with urgency but avoid random changes. Resetting the wrong credential, canceling a payment method, deleting an account, or moving a domain before understanding dependencies can turn a communication problem into an outage.

Decide whether this is a delay or an abandonment

Check every agreed communication channel and the contract's notice procedure. Send one concise written request that identifies the project, urgent operational issue, specific access or deliverable needed, and a reasonable response deadline.

Use known company contacts, project managers, billing contacts, repository profiles, and emergency support details. Avoid public accusations while facts remain uncertain.

If the software is live and at risk, continue the technical recovery in parallel. You do not need to wait for a formal dispute to preserve your own data and client-controlled accounts.

Freeze avoidable changes

Until the environment is understood:

• Do not cancel hosting, database, domain, email, or API subscriptions.
• Do not upgrade frameworks or production packages casually.
• Do not rotate a production secret without mapping every consumer.
• Do not deploy a replacement build over the only working version.
• Do not delete former accounts before preserving logs and ownership evidence.
• Do not promise customers a recovery time without a technical assessment.

Record the current date, system status, visible version, recent incidents, active users, and any scheduled business events that raise the impact of downtime.

Inventory every account and dependency

Create one table with service, purpose, URL, legal owner, administrator, billing owner, recovery method, renewal date, current status, and next action.

Include:

• Source-code repositories and issue trackers.
• Cloud, server, container, and deployment platforms.
• Databases, file storage, queues, caches, and scheduled jobs.
• Domains, DNS, certificates, and content-delivery services.
• Email, text messaging, phone, and notification providers.
• Identity, payment, accounting, maps, analytics, and other APIs.
• App-store, signing, distribution, and device-management accounts.
• Monitoring, logging, error tracking, backups, and security services.
• Design files, documentation, password vaults, and support systems.

Review company email, invoices, credit-card statements, password managers, browser profiles, and prior proposals for service names. Do not expose credentials in an ordinary spreadsheet; track access status, not the secret itself.

Preserve the current code

Locate the repository and confirm it contains the version running in production. A ZIP file from six months ago is not necessarily the current system.

Preserve branches, tags, commit history, releases, issues, pull requests, deployment records, and package lock files. Create a protected backup under company control without rewriting history.

If no repository is available, a replacement may be able to retrieve deployed artifacts or server files, but those may be compiled, incomplete, or missing build configuration. Treat recovery as an investigation rather than assuming the production server is a usable source archive.

Back up and export business data

Confirm recent backups exist and test whether they can be restored into an isolated environment. A green "backup successful" message does not prove recovery.

Export important records in documented, commonly usable formats where possible. Preserve attachments, identifiers, timestamps, relationships, audit history, and reconciliation totals. Do not change or extract regulated or confidential data without approved security and legal procedures.

Record the data source, export time, row or file counts, and checks used to confirm completeness.

Protect client-controlled access

After the dependency inventory is reliable, make sure the business controls administrative recovery, billing, and multifactor authentication for essential accounts.

Rotate credentials when there is a real security need, but do it through a planned sequence. Update every known consumer, observe logs, and retain a rollback path. Revoke former access after necessary evidence is preserved and replacement administration is working.

If unauthorized access or compromise is suspected, use qualified incident-response help rather than treating the situation only as a vendor transition.

Collect the commercial record

Preserve the signed agreement, statements of work, estimates, invoices, payment records, requirements, design approvals, demonstrations, acceptance messages, change requests, support promises, and ownership terms.

This record helps counsel evaluate rights and helps the replacement distinguish incomplete scope from a new request. Do not ask the new developer to make a legal ownership determination.

The guide on custom software source-code ownership explains why code, accounts, licenses, data, and practical handoff must be reviewed separately.

Document what is working and what is unfinished

Create four lists:

• Working and business-critical: behavior that must not regress.
• Broken or dangerous: security, data, financial, outage, and access risks.
• Promised but incomplete: tied to written scope and evidence.
• New ideas: useful requests that were never part of the original agreement.

Record reproducible examples, affected users, dates, screenshots, logs, expected behavior, and business impact. Avoid a single statement such as "the app is 80 percent done."

Buy an assessment before authorizing repairs

A replacement developer needs enough time to inspect the repository, build process, architecture, dependencies, data, infrastructure, security exposure, tests, and current production behavior.

The first deliverable should be a recovery decision, not a promise to finish everything. Ask for:

• Access and asset inventory.
• Build and deployment result.
• Architecture and dependency summary.
• Critical security, data, and continuity risks.
• Known working and failing scenarios.
• Ownership and third-party questions for the client or counsel.
• Stabilize, complete, replace, or decommission options.
• Estimated hours and assumptions for the next phase.

At Vertinus's $49.99 hourly rate, a 20-hour initial assessment is about $1,000 and a 60-hour assessment about $3,000. The right depth depends on system size, access, risk, and documentation.

Stabilize before finishing features

The safest order is often:

1. Restore client account and repository control.
2. Confirm backups and recovery.
3. Make the system reproducibly buildable and deployable.
4. Address urgent security, data-loss, and outage risks.
5. Add monitoring and operational documentation.
6. Baseline critical user scenarios.
7. Then estimate incomplete business features.

A replacement who immediately adds screens without establishing deployment and recovery may increase the risk.

Do not assume a rewrite is faster

Unfamiliar code can look undesirable before it is understood. A rewrite must rediscover behavior, migrate data, replace integrations, reproduce exceptions, test compatibility, and transition users.

Repair can be the wrong choice when ownership is unavailable, security is structurally unsafe, technology is unsupported, or the system cannot be built. Make that decision from evidence.

What to send a replacement developer

• A concise business and system description.
• The live URL and affected user groups.
• Repository and infrastructure access status.
• Technology stack if known.
• Recent backup and data-export status.
• Critical deadlines and current incidents.
• The four working, broken, incomplete, and new lists.
• Relevant scope documents without unnecessary confidential material.
• A working assessment budget.

Do not email raw production passwords. Use a secure invitation or approved credential-sharing method after evaluating the provider.

Recovery warning signs

• A new developer quotes the complete rescue without seeing code or access.
• The first recommendation is a rewrite with no assessment.
• The provider wants production administrator access before defining safeguards.
• No backup or rollback step precedes changes.
• Ownership and license questions are ignored.
• The provider promises to recover every missing feature from screenshots.
• Urgency is used to demand a large, open-ended payment.

Turn the rescue into a controlled project

The disappearance created uncertainty. The recovery plan should reduce it in observable stages: access, evidence, continuity, assessment, stabilization, then completion or replacement.

The companion article on existing codebase takeover cost explains realistic assessment and stabilization ranges.