TL;DR: When someone else builds your software, "we own it" turns out to mean three separate things, and most contracts only cover one of them. There is legal ownership, which is the intellectual property clause. There is custodial ownership, which is the repository, the history and the source files. And there is operational ownership, which is whether your business can run, change and deploy the thing without the people who built it. Companies usually discover the gap at the worst possible moment: the builder is unavailable, the product is live, and the login for the account serving it belongs to somebody else. Here is what to own, what a real handover contains, and the one test that proves you actually have one.
Ownership is three things, and the paperwork covers one
The contract question is the easy one. A properly drafted agreement assigns the intellectual property in the delivered work to you, usually on final payment, and says so in plain language. Read it for three details rather than assuming: whether assignment is conditional on payment, what happens to any pre-existing framework or library the builder brings along, and how open-source components are handled. None of those are red flags on their own. A studio that reuses its own tooling is a studio that ships faster. But you want the boundary written down: this is assigned to you, this is licensed to you, this is open source under these terms.
Custodial ownership is the next layer, and it is where quiet problems start. Owning the code in law does not help if what you receive is a zip file of the final state. You want the repository with its full history, every branch, and the issue and pull-request record if it lives on a platform you can be added to. History is not sentimental. It is how a future engineer finds out why a line exists before deleting it.
Operational ownership is the layer that decides whether you are free. It is the ability to build the software from a clean machine, deploy it, rotate a credential and fix something at nine on a Friday night. Everything else is theoretical until that is true.
The accounts nobody thinks about until they matter
The most common ownership failure has nothing to do with source code. It is that the product runs on accounts registered to the builder.
The list is longer than most people expect: the cloud or hosting account, the domain registrar and DNS, Apple and Google developer accounts for anything shipped to a store, the analytics and error-monitoring tools, email and SMS sending, the payment processor, every third-party API key, and for anything with a phone attached, the numbers themselves along with the call recordings and transcripts.
The rule is simple and worth enforcing from day one. Accounts are created by your organisation, in your name, on your billing, and the builder is invited into them. Not the other way round. Retrofitting this is possible but each item is its own small project, because an app store transfer, a number port and a domain move are three different procedures with three different waiting periods, and at least one of them will need a person who has since left.
This is sharpest in voice and communications work, which is why in the systems we build for partners like CallGuard AI and CallSetter AI, the numbers, the recordings, the agent configuration and the CRM connections sit with the business that depends on them. It is also why the question belongs in any monitoring or support retainer you sign: a fee that buys uptime while somebody else holds the account is not support, it is dependency with an invoice attached.
What a real handover contains
A handover is a deliverable, not an email. If it is not scoped and scheduled, it becomes whatever the last week of the project has time for. Ask for these ten things by name.
The repository, with full history, all branches and any related issue tracker export.
A README a stranger can follow. Not a description of the product. The exact steps from a clean machine to a running application, including the versions of anything that has to be installed first.
Environments and deployment. How staging and production are created and how a release actually reaches users, written down. If deployment is a sequence of manual clicks that one person knows, that is the finding, and it is worth fixing before handover rather than documenting.
Secrets in a manager you own. Environment variables and keys belong in a vault or secret store on your account, with a list of what each one is for. Credentials in a chat thread are not a handover.
Infrastructure as files. What runs where, defined in configuration you hold, rather than existing only as the shape of somebody's console.
The data. The schema, a documented export path, and a backup that someone on your side has actually restored once. Products that hold real operational records, like Fyuel, the real-time accounting platform we built for the fuel trade, live or die on this one, because the software can be rebuilt and the ledger cannot.
Source files, not exports. Design files, and for immersive or 3D work the original assets rather than the optimised output, which is a point we make at more length in the XR content pipeline.
A dependency and licence list, flagging anything with a commercial licence, a paid tier or a renewal date attached.
Decisions worth knowing. A short architecture note and an honest list of the choices that would look strange without context, including the compromises. Two pages of this saves a future team a month.
The access list itself. Every account, service and third-party contract, who owns it, who has administrator rights, and what it costs. This is the document that turns a pile of logins into something a business can manage.
The test that settles it: the handover drill
None of the above proves anything until somebody tries it. The drill is straightforward and it is the single most useful hour you will spend on this subject.
Take a person who did not build the software. An engineer on your team, a contractor, a friendly second opinion. Give them the repository and the access list, nothing else, and no access to the original team. Ask them to get it running on a clean machine, deploy it to a scratch environment, make a trivial visible change, and ship it. Time-box the whole thing to a day.
What comes back is always specific: an environment variable nobody documented, a database migration that has to be run by hand, a key that only exists on one laptop, a build step that quietly depends on a tool version, a service that was configured once in a web console and never captured anywhere. Each one is cheap to fix while the people who created it are still on the project and expensive to fix later, which is precisely why the drill belongs before final payment rather than after it.
It is the same excavation problem that makes replacing an inherited system so hard, and the reason legacy modernization projects stall in month seven. The rules that nobody wrote down are always discovered by someone who needs them urgently. A handover drill just moves that discovery to a day when nothing is on fire.
Where lock-in is legitimate, and where it is not
Not every dependency is a trap, and pretending otherwise leads to worse software. Choosing a telephony provider, a game engine, a cloud platform or an authentication service is a normal engineering decision, and you will not own any of them. Building custom SDKs that ship inside somebody else's product, as we do for Geonode's Repocket SDKs, means depending on the platforms those SDKs run on. That is the job, not a failure.
The distinction that matters is this: you do not have to own the platform, but you must own the configuration, the data and the exit path. Concretely, that means the account is yours, the settings are documented or exportable, your data can be extracted in a usable form on demand, and someone has thought about what a move would involve even if nobody intends to make one.
The same logic applies to white-label and productised arrangements. When an agency runs client work on a platform like VoiceDash, our white-label portal for voice-AI agencies, the agency should still be able to say what happens to its clients, numbers and configurations if it walks away, which is the question we put at the end of the white-label guide.
And the honest closing point on this section: the real lock-in is rarely the code. It is knowledge. A team that has held a system for two years knows things that no repository contains, and that is true of an internal team as much as an external one. Documentation and the drill are how you convert some of that into something transferable. Talent augmentation, where the engineers work inside your process and your repository from the start, is the other way to keep the knowledge on your side of the line.
Buyer checklist
Ask these before you sign, not before you leave.
- What exactly is assigned to us, and what is licensed? Get pre-existing components and open-source terms named in writing.
- Whose name is on the accounts? Cloud, domain, stores, API keys, phone numbers. If the answer is theirs, ask when that changes and what the transfer involves.
- Is handover a scoped deliverable with a date? If it is not in the plan it will be improvised at the end.
- Will you do a handover drill before final payment? A confident builder will offer this before you ask.
- Where do secrets live, and who can rotate them?
- Can we get a full data export today, and has a restore been tested?
- If we stopped working together next month, what would the first week look like? Listen for a specific sequence. Discomfort with this question is itself the answer.
None of this is adversarial, and none of it says anything about trust. Good builders want you portable, because a client who could leave and does not is a much better reference than a client who cannot. Scope it into the first build rather than treating it as an exit procedure, and ownership stops being a conversation you have to have under pressure.
Null Studio builds software you can actually hold: your accounts, your repository, full history and a handover we will rehearse with you before the last invoice. Book a demo and we will tell you honestly what a clean handover of your current project would take. See our work: Fyuel, Geonode's Repocket SDKs, CallGuard AI and more, shipped in days, not months.