Project handover: what you receive when development is finished
Development does not end when the contractor says “done”. It ends when the client can use the system and, if needed, develop it without us. That is why we plan the handover from the first documents of a project.
Done means running in production
Our definition of done is simple: everything described in the specification is built, deployed on the production server and working. A demo on a developer’s machine or a test environment is an intermediate step, not the result.
Acceptance criteria before work starts
How a feature is judged complete is written into the specification in advance. If criteria are invented at handover, a dispute is inevitable: by then the client and the contractor expect different things. A list agreed up front removes that dispute.
Checked by the people who will use it
Acceptance testing is done by the client’s real users — the staff who will work with the system every day, not only the manager who signs off. We test in a separate environment, not on production data. Feedback works best as a list: one message, one problem; we mark what is critical and what is not. Fixing the defects found during acceptance is part of the project. New wishes are a change of scope and are discussed separately.
What is handed over
- Source code: the repository goes to the client, and a working copy stays on their server.
- Access to the server, the admin panels and the database.
- Domain, email, analytics and the SSL certificate — set up and working.
- Documentation: an administrator guide and a description of the deployment.
- A backup of the database and files as of the handover.
At handover the client changes the passwords and keys issued during development, so that only their team keeps access.
The final meeting and the rights
The handover ends with a meeting at which we go through this list together with the client. Once the acceptance act is signed and the final invoice paid, the rights to the result pass to the client, and the warranty period and its start date are fixed in writing.
Why it matters
A system that can be launched, understood and developed without its original team is easier to maintain and cheaper to change. That is why handing over code, access and documentation is a required part of our work, not an extra service.