Developer abandoned your software project: what to do in the first seven days

Your developer has stopped replying. A release is unfinished, customers may still depend on the application and nobody inside the business is confident about what happens next.

When a developer abandons a software project, the first week should not be spent rushing into a rewrite or hiring the first available programmer. The immediate job is to regain control: protect the live service, secure the business’s access, preserve the evidence and work out what can be continued safely.

The sequence matters. A well-managed first seven days can prevent avoidable downtime, lost source code and an expensive false start.

Before day one: decide whether this is an emergency

Treat the situation as urgent if customers cannot use an important workflow, data may be at risk, a domain or certificate is close to expiry, payments are failing, or the departing developer still controls critical accounts.

Nominate one person to coordinate decisions and record what happens. Avoid making several untracked changes at once. If the application is still operating, an impulsive password reset, server change or deployment can turn a difficult handover into a production outage.

The goal of the first week is controlled recovery, not instant perfection.

Day 1: stabilise the business situation

Start with the application from the user’s point of view. Write down the customer and staff activities that must continue: signing in, taking payments, creating orders, sending notifications, producing reports or exchanging data with another system.

Then record what is happening now:

• Is the application live, partly built or not yet released?
• Are customers experiencing failures?
• Is a release or data migration in progress?
• When was the last known successful deployment?
• Who can approve urgent decisions?
• Is the former developer unavailable, in dispute or simply unable to continue?

Pause non-essential feature releases until somebody understands the deployment and rollback process. Keep support channels open and give staff a simple way to report new symptoms. Do not delete accounts, servers or project records; they may be needed to understand the system or resolve a contractual issue.

By the end of day one, you should have a named business owner, a short list of critical workflows and a shared incident log.

Day 2: secure access and establish ownership

Create an access register covering every service the application depends on. Common gaps include:

• source code repositories and issue trackers;
• cloud, hosting and server accounts;
• domain registration, DNS and SSL certificates;
• databases, file storage and backups;
• deployment pipelines and environment settings;
• Apple and Google app-store accounts;
• email, SMS, payment and identity providers;
• analytics, monitoring and error-reporting tools; and
• design files, documentation and third-party licences.

For each service, record the business owner, current administrators, renewal date and whether the account is held in the company’s name. Create at least one verified company-controlled administrator before removing or changing another user’s access.

If access may be compromised, rotate credentials and revoke former-user sessions in a controlled order. Start with the accounts that can change ownership, production infrastructure or customer data. Enable multi-factor authentication and store recovery details in a company-controlled password manager.

Do not reset credentials blindly. A password may be used by a running integration, scheduled job or deployment pipeline. An incoming engineer should help identify machine credentials before they are changed.

Day 3: preserve the code, data and operating evidence

Make independent, access-controlled copies of the assets you can recover:

• the source repository with its full history and branches;
• the current production database and uploaded files;
• infrastructure and deployment configuration;
• environment-variable names and a secure record of required secrets;
• build artefacts and mobile signing materials;
• design files, requirements, tickets and acceptance notes; and
• logs, monitoring history and recent incident records.

Confirm that automated backups exist, when the last successful backup ran and who can restore it. A backup is not dependable merely because a dashboard says it completed. Plan a restore test in a safe environment.

Keep sensitive data and credentials out of ordinary documents and chat messages. Preserve an audit trail showing what was copied, where it is stored and who has access.

If the developer still responds, request one structured handover rather than a stream of informal explanations. Kitek’s software application takeover checklist covers the access, continuity and system information to collect.

Day 4: map the system that is actually running

Inherited documentation is useful, but the live system is the source of truth. Map the main components, environments, integrations and data flows. Identify which external providers support critical workflows and which manual processes staff use when something fails.

At minimum, the map should answer:

• Where does the application run?
• Which database contains production data?
• How does a code change reach production?
• Which services send email, messages or payments?
• Which scheduled jobs and integrations move important data?
• Where are errors recorded and who receives alerts?
• What happens if the application becomes unavailable?

This is also the time to compare invoices and subscriptions with the technical inventory. An active cloud account or third-party service can reveal a dependency that was never documented.

The result does not need to be a perfect architecture diagram. A one-page current-system map is enough to expose missing ownership and guide the technical review.

Day 5: prove that the software can be built and changed safely

An incoming engineer should try to reproduce the application in a controlled development or staging environment. The objective is to find out whether the code you have can produce the system customers are using.

The review should test:

• whether dependencies can still be installed;
• whether the application builds and starts;
• whether automated tests run and what they cover;
• whether database migrations are complete;
• whether a staging environment resembles production;
• whether deployment steps are repeatable; and
• whether a failed release can be rolled back.

Do not make a cosmetic code-quality score the centre of the assessment. The most important question is whether the team can make a controlled change without risking customers, data or business continuity.

If production is unstable, agree on the smallest safe intervention and a rollback route before changing it. New features can wait until release control is restored.

Day 6: rank risks and review the commercial position

Turn the evidence into a short risk register. Rank each issue by business impact, urgency and confidence in the evidence. Typical first-week risks include missing company ownership of accounts, untested backups, exposed secrets, unsupported dependencies, a single unrepeatable deployment path and undocumented integrations.

Separate three kinds of work:

1. Immediate controls that protect access, data and continuity.
2. Stabilisation work that makes incidents and releases manageable.
3. Longer-term improvements that reduce technical debt or add features.

Review the development agreement, invoices, statements of work and any intellectual-property clauses. Confirm what source code, designs and licences the business is entitled to use. If ownership is disputed, obtain legal advice before making assumptions or sending formal demands.

This commercial review should run alongside the technical assessment. A sound codebase is not enough if the business cannot legally use a key component or control the account that operates it.

Day 7: choose the recovery path

By the end of the week, you should be able to choose a next step based on evidence rather than frustration.

There are usually three realistic paths:

• Continue: the application is understandable, the main assets are controlled and normal delivery can resume with a new team.
• Stabilise and modernise: the core product remains valuable, but access, infrastructure, tests or high-risk components need staged improvement.
• Replace selected parts: an essential component cannot meet security, reliability or business needs at a reasonable cost, so it should be replaced through a controlled transition.

A complete rewrite should not be the automatic answer. Rewrites can discard working business rules, introduce migration risk and delay improvements customers need now. When replacement is justified, plan the data migration, acceptance criteria, parallel operation and rollback before a final cutover.

Ask the incoming team for a 30- to 90-day recovery roadmap with clear outcomes, assumptions and decision points. It should explain what will be secured first, how safe releases will be restored and when feature development can restart.

What you should have after seven days

A useful first week produces concrete evidence:

• a named business owner and decision process;
• company-controlled access to critical services;
• recoverable copies of code, data and documentation;
• a current-system map;
• a tested or testable build and deployment path;
• a prioritised risk register; and
• a staged recovery recommendation.

You may not have every answer. That is normal. The objective is to replace uncontrolled uncertainty with a safe way to learn and act.

What not to do when a developer disappears

• Do not deploy major changes immediately. First establish how production and rollback work.
• Do not rotate every password at once. Running integrations may depend on credentials that have not yet been identified.
• Do not assume poor documentation means the product is worthless. The live system and repository may contain enough evidence for an experienced team to recover it.
• Do not commit to a rewrite before an audit. Repair, isolation or staged modernisation may deliver value sooner and with less risk.

The calm response is the faster response: secure, preserve, understand, then change.

Need help recovering an abandoned software project?

Kitek helps Australian businesses take control of stalled, unsupported and business-critical web and mobile applications. We begin with the evidence: access, code, infrastructure, data, deployment and operational risk. You receive a prioritised risk view and a practical recovery roadmap before major new work begins.

Explore Kitek’s software rescue and project takeover service →