The Short Answer
When a developer leaves an unfinished project, first secure access and preserve the current state. Do not rush into new feature work until the code, hosting, database, credentials, and ownership picture are understood.
The goal is to turn a stressful handoff into a controlled review.
Immediate Steps
Gather repository access, hosting access, domain and DNS access, database access, environment variables, third-party service accounts, documentation, backups, and any deployment instructions. Confirm which accounts belong to the business rather than the former developer personally.
Create backups before changing anything important. If the software is live, avoid exploratory changes on production.
Collect and verify
- Code repositories and branch status
- Hosting, deployment, domain, and DNS accounts
- Database credentials and recent backups
- Environment variables and API keys
- Admin accounts and user permissions
- Documentation, designs, invoices, and scope notes
Review Before Continuing
A technical review should answer what works, what is unfinished, what is risky, what can be reused, and what needs rebuilding or cleanup.
Only after that review should the business decide whether to finish the existing implementation, reduce scope, repair the foundation, or plan a new version.
Stabilize Before Resuming Work
The most important early decision is to avoid changing unknown software under pressure. A new developer should first preserve the current state, understand how it runs, and identify what is safe to touch.
The business should confirm ownership of accounts and assets. Code, domains, hosting, databases, designs, licenses, and third-party services should belong to the company or be transferable to it.
Then the unfinished work can be separated into categories: complete, partially complete, unclear, risky, and missing. This prevents the next phase from relying on assumptions left by the handoff.
A review may reveal that finishing the project is straightforward. It may also show that the safest path is reducing scope, repairing the foundation, or rebuilding a specific part.
Do before feature work resumes
- Back up code, database, and important files
- Confirm access to hosting, domains, and repositories
- Document how the current version runs
- Identify unfinished or risky areas
- Create a practical recovery plan
Communicate the State Clearly
After an unfinished-project handoff, stakeholders need a plain-language picture of where things stand. That includes what works, what is incomplete, what is unknown, and what should not be changed yet.
Clear communication prevents the project from restarting with the same confusion. It also helps the business make practical choices about scope, launch, budget, and risk.
The review should end with a prioritized path, not just a technical inventory. Owners need to know what must happen first and why.
A useful handoff summary includes
- Current working features
- Incomplete or unverified features
- Access and ownership gaps
- Recommended next steps