A software project handover checklist covers four things: the source code in a repository you own, every account in your name, short handover documents (setup, deployment, architecture, known issues), and a recorded walkthrough. Check all four, and have someone new run the app from the notes, before you make the final payment.
The most expensive day in many software projects comes months after launch. It is the day when a new developer opens the code, finds no notes, no passwords, and no idea how anything runs, and quotes you a week just to understand it.
A good handover prevents that day. Here is the list to check before you make the final payment.
Key Takeaways
- The handover belongs in the final milestone, so it is done before the last payment.
- You need four things: the code, the accounts, the documents, and a walkthrough.
- Test the handover by asking someone other than the builder to run the app from the notes.
- Everything should already be in your name. The handover confirms it; it should not be the first transfer.
1. The Code
- The full source code is in a repository your business owns (GitHub, GitLab, or similar).
- The latest version in the repository matches what is running live.
- Nothing important lives only on the developer's laptop.
- Any code the builder reused from other projects is identified, with its license.
2. The Accounts
List every service the app depends on, and confirm you are the owner of each, with the builder only as a user:
- Domain name
- Hosting and cloud accounts
- Database and backups
- Email sending service
- Payment provider
- App store accounts, if there is a mobile app
- Analytics and error tracking
- Any paid APIs or third-party tools
For each: who pays the bill, which card it is on, and when it renews. Then remove the builder's access where they no longer need it, or agree when that will happen. See accounts you should own before a developer builds your app.
3. What developer handover documentation should you get?
These do not need to be long. They need to exist.
| Document | What it answers |
|---|---|
| Setup guide | How a new developer gets the app running on their computer |
| Deployment guide | How a change goes from code to the live app |
| Architecture overview | The main parts and how they connect, on one page |
| Secrets list | Which passwords and keys exist, and where they are stored (not the secrets themselves in a plain document) |
| Known issues | Bugs and shortcuts that were left on purpose |
| The "later" list | Features discussed and not built |
| Running costs | What the app costs per month and why |
4. The Walkthrough
- A recorded call, 30 to 60 minutes, where the builder shows the code structure, how to deploy, and where the tricky parts are.
- A way to ask follow-up questions for a period after handover.
The recording is worth more than it sounds. A new developer can watch it on day one.
5. How do you know the handover is complete?
Before the last payment, give the setup guide to someone who has not worked on the project (a freelancer for a couple of paid hours is enough) and ask them to get the app running and make a trivial change. If they cannot, the handover is not done.
A Concrete Version
An owner's inventory app is finished. The final milestone reads: "Launch, handover package, 30-minute walkthrough."
The owner goes through the list and finds three gaps. The email sending service is on the developer's personal account. There is no deployment guide, because the developer "just runs a script." And the known-issues list is empty, which is unlikely for any real app.
The owner raises all three before accepting the milestone. The email account is moved to the business, the developer writes a one-page deployment guide, and the known-issues list gets four honest entries (including a slow report page). A freelancer spends two hours following the setup guide, hits one missing step, and it is added.
Total extra time: about a day. It saves the next developer many times that.
The Honest Counterpoint
A perfect handover package can become its own project, and small builds do not need one. For a $5,000 app, a clean repository, accounts in your name, a one-page setup guide, and a recorded call are enough. Also, documents go stale. The better protection is good habits throughout the project: code in your repository from day one, accounts in your name from day one. The handover then confirms what is already true. On our software factory projects, the handover is part of full IP transfer: you own everything we build, including code, designs, and documentation.
Frequently Asked Questions
What should a software project handover checklist include?
The source code in your own repository, matching what's live; ownership of every account the app depends on; a setup guide, deployment guide, one-page architecture overview, secrets list, known issues and running costs; and a recorded walkthrough with a period for follow-up questions.
What if my developer has already left?
Start with what you control: the domain and hosting. Then read what to do when a developer won't hand over your code.
Should the handover cost extra?
It should be part of the price and written into the last milestone. If it is not in your contract, ask for it before you start. See fixed-price software contract: what to include.
Who will maintain the app after handover?
Decide before handover. Options include the same builder on a retainer or a new developer. Read how to hire a developer to maintain an existing app.
The Bottom Line
Code, accounts, documents, walkthrough, and a test by someone new. Put it in the last milestone and check it before you pay. If you are planning a new build and want ownership handled from the first day, start with the honest read. Related: what happens after your app is built.
Roberto Espinoza is CEO of Ruzora, which builds custom software for business owners at a fixed price and helps US teams hire pre-vetted senior LATAM engineers. Get a free honest read on your idea.
