A costly software problem can start without a bug: a company owns a product nobody on their side can change.
It happens gradually. The build goes fine. The launch goes fine. Then the agency's contract ends, and it turns out the deployment runs from one engineer's laptop, the environment variables live in a Slack message, and no document anywhere explains why the billing job runs at 3am.
That product is not finished. It is hostage.
What to agree for the handover
The right handover depends on the product, its hosting, and who will maintain it. These are useful topics to settle in the proposal, rather than assume every engagement includes them.
Repository access and ownership. Agree where the code lives during the build, who can access it, and what source files and history will transfer at handover. Distinguish project work from existing tools and third-party code with separate licences.
Account responsibilities. Identify the owner of hosting, domains, monitoring, store listings, and payment accounts. Agree how access is granted and removed, including any platform restrictions or separately managed services.
Useful setup instructions. Document how to install, run, test, and deploy the project where relevant. Agree who will try those instructions and what a successful handover check looks like.
An architecture note. Explain the main pieces, how they connect, and why important decisions were made. Match the detail to the system and the people who will maintain it.
A repeatable release process. CI deployment may suit the project; other platforms need different release steps. Document the agreed process, required access, and recovery responsibilities.
A walkthrough where useful. A live session or recording can explain admin areas, scheduled jobs, and common recovery steps. Include the format and coverage in the handover scope.
How to check before you sign
Ask any prospective partner these three questions:
- Where will the code live during the build, and what access and ownership will we have? Agree the arrangement and any transfer conditions before work starts.
- What exactly do we receive at handover? If the answer is vague, the handover will be too.
- Can we take this to another developer without you? Watch how comfortable they are with the question.
At Devlumio, handover deliverables, ownership, licences, and transfer conditions are agreed in writing. Ongoing maintenance is scoped separately. The aim is a clear understanding of what you receive and who is responsible for the next step.
The other reason it matters
Building for handover makes the software better while you build it. Code you know a stranger will read gets clearer names. Infrastructure you know someone else will run gets documented. Decisions you know you will have to justify get made more carefully.
Writing for an audience improves the writing. The same is true of code.