In this article (7)
The question nobody asks until it is too late
Companies negotiate hard on scope and schedule, then discover at the end that the repository sits in the agency's account, the hosting is on their card, and the documentation is a conversation with a developer who has moved on. Nothing dishonest happened. The handover was never specified, so it never got produced. Settle this at contract stage, when you have leverage, rather than in the final week when the leverage is entirely on the other side.
The code, in a place you control
Ownership of the source is the headline, and it is worth less than people assume if the repository lives in the supplier's organisation. Ask for the code to be pushed to an account you own from the first week, not transferred at the end, so the arrangement is tested continuously rather than promised. Full commit history matters too: a single dump of files on the last day loses the record of why anything was done the way it was.
Everything the software runs on
Code alone does not run. You need the hosting and domain registrar accounts in your company name, the database and its backups, environment variables and API keys, any third-party subscriptions the system depends on, and the deployment pipeline. Accounts registered to a developer's personal email are the most common failure point, and they usually surface at the worst moment, when someone has left and nobody can reset a password.
Enough documentation for a stranger
The test is whether a developer who has never met the original team can set the project up locally and deploy a change. That means a README that actually works, an architecture note explaining the main decisions, the rules encoded in the business logic written in plain language, and a runbook for the things that break. Documentation written for the people who already know everything is decoration, and it is what most projects hand over.
Talk to us about a build on WhatsAppDesign files, not exports
The same trap applies to anything visual. A folder of PNGs is not a handover; the editable sources, the component library and the fonts with their licences are. Companies routinely find they own the finished website and cannot change a single page without going back to the supplier, which is the same dependency in a different form and the reason building rather than buying only pays if you actually receive what was built. If there is a brand system attached, the assets that make guidelines usable belong in the package too.
Write the exit into the agreement
A clear termination clause with reasonable notice, defined handover obligations, what happens to work in progress, and what the supplier must deliver on the way out. This is not distrust and no competent partner objects, because ambiguity at the end damages them as much as you. The presence or absence of a straight answer here tells you a great deal about who you are dealing with, and it belongs on the list when choosing a development partner.
Test the handover before you need it
The only way to know a handover is real is to use it. Have someone outside the project clone the repository, follow the documentation and deploy a trivial change while the original team is still available to answer. Do it a month before the end, not on the last day. The same rehearsal is what makes replacing a legacy system survivable. Every gap you find is free to fix now and expensive later, which is the whole argument for treating the exit as a deliverable of the platform work rather than an afterthought.
Written by
Idennex
Strategy-first agency, Istanbul