Short answer: when a software project ships, you should own the source repository, the cloud account the application runs on, the domain and its DNS records, every third-party service account and its billing, the production database with a restore you have tested yourself, and the right to keep building without the original team. Ownership is not a clause in a contract — it is whether you can log in and change each of those things this afternoon.
Most handovers fail in parts rather than all at once, and the parts that fail are predictable. This is the inventory to run, the items that quietly stay behind, and what to agree in writing before the first line of code.
What you should own the day the project ships
The list is shorter than most buyers expect, and every item on it controls something you will need to change at some point, usually under time pressure.
- The source repository, in your organisation or your own account, with its full history. A zip of the current version is not the project; it is a snapshot with the reasoning removed.
- The cloud or hosting account the app runs on, with the billing method in your name. This single item decides whether your product keeps running when a working relationship ends.
- The domain registration and the DNS zone. Whoever can edit DNS controls your traffic, your email and your verification records, and those edits are easy to disguise as housekeeping.
- Third-party accounts — payments, transactional email, SMS, maps, analytics, error monitoring — created under your organisation rather than the vendor’s.
- The production database, plus a restore you have performed yourself. An export nobody has restored is an untested file, not a backup.
- Secrets held in a password manager you control, with the developers named as users rather than owners.
- Runbooks: how to start the application locally, how to deploy, what each environment is for, which integration is which, and who is called when a scheduled job fails at 3am.
Access is not ownership
Handover problems are rarely a flat refusal. They are partial transfers that look complete until the day the other party is unavailable, busy, or prioritising something else.
- Invited, not owned. You hold an administrator invite on the vendor’s account. The access is real; the ownership is not. Removing an invite takes one click.
- Only production moved. Staging, the build pipeline and the scheduler stay behind, so nothing can be tested before it reaches customers.
- Personal accounts as infrastructure. A developer’s own email address or phone number holds the password-recovery path for a service your business depends on. When they leave, the recovery path leaves with them, and rebuilding it can mean proving to a platform that you own an account you never created.
- A document of passwords instead of a manager. It is stale within weeks, it gets forwarded freely, and nobody can say who has used which credential.
- Non-transferable licences. A paid component, theme, map licence or font licensed to the vendor cannot simply be reassigned to you. That is not a paperwork gap; it is a rewrite waiting to be discovered.
What a late handover actually costs
Skipping the inventory does not save money. It moves the cost to the worst possible moment, and there are three familiar versions of the bill.
- The departure bill. The only account with production access belongs to someone who has left. Recovering it means reverse-engineering a live system while customers are watching.
- The hostage bill. Routine work is quoted as new work, because releasing the application now requires the original team’s cooperation. Every change is priced with that leverage built in.
- The rebuild bill. The code is yours, but nothing around it is: no pipeline, no infrastructure definition, no documented integrations. The next team spends its first weeks reconstructing context instead of adding value.
All three are avoidable with one list, agreed before the project starts, when you still have leverage and the vendor still wants to win the work.
What to agree before work begins
Put these six points in the proposal or contract. They cost nothing to write and they remove the negotiation that otherwise happens at the worst time.
- An asset schedule. Name the repository, the cloud account, the DNS zone, each third-party service and who the owner is from day one.
- Owner, not admin. You are the account owner; the vendor is added as a user with the access the work requires. Access to production should be named, not shared.
- Transfer timing. Ownership exists from the start of the work, not on final invoice or on request. Where a vendor wants protection against non-payment, use a payment schedule rather than retained ownership of languages, accounts and infrastructure.
- An acceptance test for the handover. State the test in the contract: a developer who has never seen the project can build and deploy it from your accounts alone.
- A continuity clause. If the vendor stops trading or the relationship ends, what happens to access, to the running systems, and to the licences that are not in your name.
- A warranty window. A stated period after handover in which defects in the delivered work are fixed without argument.
How to test a handover in one afternoon
Do not test a handover by reading a document. Test it by watching someone who is not the original developer do the work. Book a session and ask them to run the whole chain on a clean laptop: clone the repository, find the credentials in your password manager, start the app locally, deploy to staging, then fix one small defect through to production and confirm it arrived. Everything missing from the handover shows up inside those two hours, and every gap is cheaper to fix that afternoon than a year later.
Frequently asked questions
Who should own the source code while the project is still in progress?
You should, from the first commit, in a repository you control. Vendors who want protection against non-payment can be paid in stages, and a staged schedule is a better instrument than withholding the repository — retained ownership mainly guarantees that a dispute becomes a technical problem as well as a commercial one.
Can we rent the vendor’s infrastructure instead of owning our own account?
You can, and sometimes it is genuinely cheaper while a project is small. The trade is control: your application then lives inside someone else’s billing relationship, and moving it later means migrating a running system rather than starting in the right place. If you accept that trade, put a migration clause and a cost ceiling in writing so leaving has a defined price.
What is the single most common thing missing from a handover?
The recovery path to a third-party account: the email address and phone number that can reset the password. It is invisible until it is needed, and it is the item most likely to sit with a person rather than with the business.
Should we host the application ourselves instead?
Only if someone on your side owns deployment as a job. Self-hosting that nobody maintains usually produces a worse outcome than managed hosting with clear ownership, because the risk moves from a contract you can renegotiate to an outage nobody is paid to prevent.
How long should a handover take?
Days, not months, if the assets were set up correctly at the start. A handover that is being assembled from scratch at the end is a sign the ownership question was answered late, and the work involved is the same list this article recommends agreeing up front.
Next step
If you are comparing suppliers now, our breakdown of how to choose a software development agency covers the assumptions to compare before a contract, and custom app development sets out how we scope and build. Every project we deliver runs in accounts the client owns from day one, with the handover test above written into the plan. Request a scope and quote, or read what a full engagement includes.