The project is "done." But what exactly do you walk away with?
A proper handoff determines whether you actually own your software or remain dependent on the people who built it. Here's what to expect.
The Complete Handoff Checklist
1. Source Code
What: All the code that makes your software work.
You should receive:
- Complete, current source code
- In a repository you control (GitHub, GitLab, Bitbucket)
- With full commit history (not just final files)
- Including all branches
Why it matters: Without source code, you can't make changes, hire other developers, or truly own what you paid for.
Red flag: "We'll give you access when you need it" — you should have it now.
2. Documentation
What: Everything needed to understand and operate the system.
You should receive:
- Technical documentation (architecture, how it works)
- User documentation (how to use it)
- Admin documentation (how to manage it)
- API documentation (if applicable)
- Database schema
Why it matters: Documentation enables independence. Without it, you're calling the original developers for everything.
Red flag: "The code is self-documenting" — no, it isn't.
3. Deployment Information
What: How to get the software running.
You should receive:
- Deployment procedures (step-by-step)
- Server/infrastructure configurations
- Environment variables and settings
- CI/CD pipeline access (if automated deployment exists)
Why it matters: You need to be able to deploy updates, restore from backup, or move to new infrastructure.
Red flag: Only the original team can deploy it.
4. Access Credentials
What: All the keys to your kingdom.
You should receive:
- Admin accounts for the software itself
- Server/hosting access
- Database access
- Third-party service credentials (payment processors, email services, etc.)
- Domain registrar access
- SSL certificate management
- Monitoring/analytics access
Why it matters: If you don't have credentials, you don't have control.
Red flag: Credentials stored only with the development team.
5. Third-Party Account Ownership
What: Accounts with external services.
You should receive:
- Transfer of ownership (or creation under your accounts)
- AWS/GCP/Azure accounts
- Stripe, Twilio, SendGrid, etc.
- Domain registration
- Analytics accounts
Why it matters: Services tied to someone else's account can disappear when that relationship ends.
Red flag: Everything running on the developer's personal accounts.
6. Design Assets
What: Visual design files.
You should receive:
- Logo files (vector format)
- Design system/style guide
- Source design files (Figma, Sketch, etc.)
- Icons, illustrations, images
Why it matters: Future design work needs these source files.
Red flag: Only final exported images, no source files.
7. Training
What: Knowledge transfer.
You should receive:
- User training (for your team)
- Admin training (for your IT)
- Technical walkthrough (for future developers)
- Recorded sessions (for reference)
Why it matters: Documentation helps, but live training fills gaps.
Red flag: No training included, "just read the docs."
8. Support Period
What: Post-launch safety net.
You should receive:
- Defined support period (30-90 days typical)
- Bug fixes for issues discovered
- Clarification and questions answered
- Clear escalation process
Why it matters: Problems surface after launch. You need a runway.
Red flag: Support ends the day of launch.
The Handoff Meeting
Don't just receive files. Have a formal handoff:
Agenda:
- Review all deliverables against checklist
- Verify access to all systems
- Test credentials work
- Walk through critical procedures
- Document any outstanding items
- Establish support protocol
Who should attend:
- Your technical person (if you have one)
- Key users
- The development team lead
- Anyone who will maintain the system
What to Verify
Before signing off:
- [ ] Can you access the source code repository?
- [ ] Can you deploy the application yourself? (Or know who can?)
- [ ] Do you have admin access to the live system?
- [ ] Do you control all third-party accounts?
- [ ] Is documentation accessible and understandable?
- [ ] Do you have contact info for questions?
- [ ] Is the support period clear?
Common Handoff Failures
"We'll transfer that later"
Later often means never. Get everything at handoff.
Missing Third-Party Access
The software works, but you can't access the email service or payment processor. Suddenly you're dependent.
Documentation That Doesn't Exist
Promises of documentation that never materialized. Insist on it before final payment.
Tribal Knowledge
Key information only exists in developers' heads. Push for documentation.
No Transition Period
Day 1: development team. Day 2: you're alone. Build in overlap.
Protecting Yourself
Contract Provisions
Your contract should specify:
- All deliverables listed above
- Final payment contingent on complete handoff
- Source code ownership clear
- Support period defined
Escrow (For High-Stakes Projects)
Source code escrow ensures you get code even if the vendor disappears.
Parallel Verification
Have someone technical review what you're receiving before signing off.
The Bottom Line
A project isn't done when the software launches. It's done when you have complete ownership and independence.
Don't let excitement about launch distract from proper handoff. The completeness of handoff determines your freedom going forward.
We believe in clean handoffs that set you up for success. Let's talk about your project