Amine
5+ years software engineer
5+ years software engineer
5+ years software engineer
5+ years software engineer
5+ years software engineer
A handover is complete when a different developer could take over without speaking to the previous one. That's the standard. Anything less and you have a product you can run but not a product you own in any practical sense.
Agree this list before the build starts, not at the end. At the end it reads as distrust; at the start it reads as professionalism, and any good developer will simply say yes. Part of how to hire a developer for your MVP.
1. The Git repository, in your organisation, with full commit history. Not a zip file of the current code. The history is the record of who wrote what and when, and it's the first thing technical diligence asks for during funding or acquisition. A repository with a single "initial commit" containing everything is a warning sign.
2. All branches and tags that matter, not just the main branch.
3. The code builds from a clean checkout. See the verification test below.
4. Deployment instructions written down, step by step, in the repository.
5. Infrastructure configuration. Whatever defines your servers, hosting, and services — in the repo where possible rather than living only in someone's account.
6. Environment variables documented. A list of every configuration value the app needs, what each one does, and where to obtain it. Not the secret values in a text file — the inventory, so a new developer knows what has to exist.
7. Any build or deploy pipeline in your accounts, working. If deploys currently only happen from the developer's laptop, that's not finished. My CI/CD guide is written for developers, but the short version is that a deploy nobody but one person can run is a dependency, not a process.
8. Database schema and migrations. Migrations matter — they're how the database structure changes safely in future. Without them, the next developer is modifying a live database by hand.
9. A backup, and a documented backup process. Including how to restore it, which is the half people skip.
10. Any seed or reference data the app needs to function.
11. Design files in an editable format, in your account — not exported PNGs.
12. A README that explains how to run the project locally. This single file is the strongest signal in the whole handover. If a developer has written a clear one, they've thought about the person who comes next.
13. API documentation if the product has an API or a mobile client talking to a backend.
14. Every account under your company, with you as owner. GitHub, cloud provider, domain registrar, database, email, payments, analytics, error tracking. This should already be true from day one — see who owns the source code — but verify it now.
15. Credentials transferred, or a documented process for rotating them. Best practice is that you rotate every secret at the end of an engagement anyway.
16. The signed IP assignment, if it isn't already in the main agreement.
You can check most of this yourself.
The clean-checkout test. Ask the developer to prove the project builds and runs from nothing but the repository plus the documented environment variables — ideally on a machine that isn't their usual one. This one test catches most incomplete handovers, because it surfaces the undocumented step that only exists on their laptop.
The someone-else test. The real standard. Pay an independent developer for two hours to clone the repo, follow the README, and get it running. If they can, your handover is real. If they can't, you've found the gap while you still have leverage — the final payment.
Two hours of an independent developer's time is the cheapest insurance in this entire process.
Check the accounts yourself. Log into GitHub, your cloud provider, and your domain registrar. Confirm you are the owner, not a collaborator. This takes ten minutes and it's the item with the highest cost of being wrong.
Open the README. You don't need to understand the commands. You can tell the difference between a page of clear instructions and an empty file.
The last milestone payment should sit after handover, not before it.
Not because developers are untrustworthy — most aren't — but because handover is the least interesting part of a project and it's the first thing that gets deprioritised when the next contract has started. A payment sitting behind it is what keeps it on the calendar.
Make it explicit in the agreement so it isn't a surprise. Framed upfront, it's normal contract structure. Introduced at the end, it feels like an accusation.
It happens, often without bad intent — a developer moves to the next project and the documentation never gets written.
Be specific rather than general. "The handover is incomplete" starts an argument; "the README doesn't include the environment variables needed to run it locally, and the deploy currently only works from your machine" gets fixed. Reference the checklist you agreed at the start, and it's a task list rather than a dispute.
If someone has genuinely gone quiet and you own every account, you're in an inconvenient position rather than a disastrous one — a new developer can work out an undocumented codebase, it just costs money. That's precisely why owning the accounts from day one matters more than any clause.
If you want an independent review of a handover you've just received, get in touch.
Four different products, not four prices for the same thing. What each option is actually good at, how each one fails, what an agency's overhead buys you, and where offshore genuinely fits.
Shortlisting, comparing proposals, spotting the agency that sells with seniors and delivers with juniors, and getting ownership in writing — the full hiring process, written from the side that receives the brief.
You can't read the code, so stop trying. Judge product thinking, process, and what they refuse to build — the eight things that actually predict whether a build succeeds, and how to check each one without technical skills.