Who owns the code you paid for

You own the code when the contract transfers it and you control the accounts it runs on, and those are two different questions. Copyright, repository access, hosting, domain, database and API keys are separate assets, and paying an invoice transfers none of them by default. The answer flips when the vendor hosts the system: you may hold the copyright and still be unable to run the product for a single day without them.

What does copyright actually give you?

By default, copyright in the code sits with the person who wrote it; a contract can assign it to you or license it. Three rights matter in practice: to use the software, to modify it, and to have somebody else modify it. A licence that grants use but forbids modification is a rental with extra steps — you can keep running the system until the day you need it to do something new.

What an engineer can tell you is the list of things that must be true on the day you want to leave. What the clauses mean, and whether they survive a dispute, is a question for a lawyer. This article does not answer that, and neither should a software studio.

What has to be in your name?

Asset	Where it usually sits	What "yours" looks like
Code	A Git repository	Your account, admin rights, full history
Domain and DNS	A registrar	Your login, your card on file
Runtime	Hosting or cloud account	Your account, vendor invited as a user
Data	Database and file storage	An export you have restored once

Add to that list: the accounts for transactional mail, SMS, the payment gateway, monitoring and error tracking, the SSL certificates, the app store listings, and the administrator logins inside the application itself. Each is a separate way to be locked out.

Why does "hosted by the vendor" own everything quietly?

Nothing is hidden in that arrangement, and that is what makes it easy to accept. The system runs on their servers, under their account, deployed by their pipeline. They hold the runtime, the data, the backups and the ability to switch you off. You may own the copyright to every line, and none of it helps on the morning the relationship ends.

The same shape appears in a milder form: your domain registered with their card, your repository inside their organisation, your database credentials known to two of their employees and nobody at your company. No single decision was dishonest. Together they mean the system cannot change hands without the vendor's cooperation, which is the definition of leverage.

What should you ask for in writing?

• An assignment of copyright, or an irrevocable licence that covers use, modification, and subcontracting the modification to another developer.
• Repository access from the first week, and a copy in an account your company controls at each milestone — not an archive at the end.
• Every account created in your name, with the vendor added as a collaborator and removed at handover. Billing on your card.
• A data export clause: which format, how often, who runs it, and confirmation that it includes uploaded files, not only database rows.
• A list of third-party components and their licences. Whatever those licences require is your obligation once you own the product.
• A defects period, and what happens to bugs found after it ends.

Ask your lawyer to turn that list into clauses. The list is the part a studio can help with; the wording is not.

Why is an exit plan not a sign of distrust?

It is a design requirement, like a fire door. A vendor who knows the handover is documented behaves differently from one who knows the switch is painful: the first prices maintenance, the second prices captivity. It also protects the vendor — nobody wants to be the only person who can support a system at a price they no longer want to charge.

There is a practical test in it. A supplier who refuses to put the repository in your name, or who cannot explain how a handover would work, has told you what the relationship is before you sign anything.

Can you own the code and still be stuck?

Yes, and it is common. Owning the source without a documented build, a deployment path somebody can repeat, the environment configuration, the database migrations, the third-party accounts and one person who has performed a deploy unaided gives you a file on a disk.

The test is concrete: take a clean machine, follow the documentation, build the application, deploy it to a separate environment, restore a backup into it, and run the acceptance tests from the build. Until that sequence passes without the original developer's help, ownership is theoretical. Do it once a year, not once at the end.

The order to fix this

1. Inventory every account the system touches, and note whose name and card each one carries.
2. Move the domain, the DNS and the hosting billing to the company.
3. Get repository access, or a mirror with full history — not a zip of the current files.
4. Export the data, restore it into a separate environment, and time how long it takes.
5. Ask a lawyer for assignment and licence wording that covers modification and subcontracting.
6. Attach the account list and the handover duties to the contract as an annex.
7. At handover, remove the vendor's access and rotate every secret you can.

Where this goes wrong

• The domain is registered in the vendor's name. The site works for a year, then the renewal fails on a card that expired, and a trading business loses its address over a payment nobody was tracking.
• The code arrives as an archive. No history, no branches, no build notes, and nobody can say which files are running in production.
• The licence grants use only. You can run the system forever and change nothing, which is ownership in name.
• "We keep the servers, it is safer." It may even be true, and it is still an exit problem: safety and dependency are different things.
• Open-source obligations nobody read. A component under a copyleft licence can oblige you to publish more than you intended, and the obligation follows the product, not the vendor.
• Two suppliers share one hosting account, and neither can be removed without breaking the other.
• The recovery email on every account is the old developer's personal address.

What this does not cover

This is not legal advice. Who owns what under your jurisdiction, how employee and contractor authorship differ, what moral rights survive an assignment, and what a court would enforce are all questions for a lawyer, and the answers differ by country. Nor does it cover whether the code is worth what you paid: ownership tells you who may change the system, not whether it works or whether it was good value.

We build in your accounts, hand over the repository at every milestone, and prove a restore before the last invoice, because an exit you never need is still part of the build.