The real test of a handover is your absence
A handover is not a folder of files passed at the end of a project. It is proof that the work can continue without the studio that built it.
Every software project ends with a handover, whether anyone plans for it or not. The question is whether that handover leaves you able to run the thing yourselves, or leaves you needing to call the studio every time something breaks.
At Yunaris Technologies we build marketing sites, web applications and software as a service at a fixed price, and we treat the handover as part of the deliverable, not an afterthought once the invoice is settled. A handover done properly should make us optional. That is the whole point.
What a proper handover contains
A handover is not a single document. It is a set of things that together let another developer, or you, pick up the project without guessing.
It starts with access. You need the credentials for hosting, the domain registrar, the email provider and any third party service the project depends on, all held in accounts you control, not ones we control on your behalf.
It includes the code itself, in a repository you own, with a history that shows how the project reached its current state rather than a single flattened commit.
It includes a short written account of the decisions that shaped the build: why a particular database was chosen, why a certain page loads the way it does, what was tried and then dropped. Code shows what was built. It rarely shows why.
It includes instructions for the ordinary tasks: how to deploy a change, how to roll one back, how to read the logs when something goes wrong. These should be plain enough that a competent developer who has never seen the project can follow them without a call to us.
And it includes an honest list of what was deliberately left out, the shortcuts taken to meet the price and the timeline, and what those shortcuts would cost to fix later. Leaving that list out does not make a project look more finished. It just moves the surprise to a worse moment.
Why leaving matters
A studio that cannot leave has usually built something only it understands. That is not loyalty. It is dependency, and dependency is not a service. It is a cost that arrives later, without warning, and usually without a fixed price attached to it.
A handover you could hand to a stranger is the only kind worth calling a handover.
You should be able to give your access, your code and your documentation to a developer who has never spoken to us, and have that person understand the project within a day. If that is not possible, the handover was not finished, no matter how many files were sent across.
Fixed price work only stays fair if it ends cleanly. A studio that lingers, through unclear documentation or access it never quite releases, is charging you twice: once for the build, and once for an exit it made difficult. Ask what your handover will contain before the project starts, not after it ends.