Who owns the code when a development project ends?

If you are hiring a development team, this is the question worth asking before the first invoice, not after the last one: when the project is finished, what do you actually own?

The honest answer is that "the project" is two different things, and they are settled differently.

The accounts — hosting, domain, payment gateway, analytics, email sending, any API keys — should always be yours. Registered in your company's name, paid by you, with the agency added as a user and removable at any time. There is no good reason for it to be otherwise, and we do not accept one.

The code is whatever the contract says, and the contract should say it plainly before any work starts. There are two arrangements, and both are legitimate:

• You own the source. The actual code, in a repository you control, with its history intact. This is the usual arrangement for websites, ecommerce stores, Shopify apps and custom builds — software that exists only for your business and has no life outside it.
• You licence the software. You receive a working, supported installation rather than the source. This is how some of our packaged products are delivered, and it exists for two reasons. A product handed over as source tends to get resold, and it tends to get modified by a third party who does not know why it was built the way it was — and the faults that introduces come back to the original team to explain. A licence keeps the product intact and keeps support meaningful.

Neither is the trick; the trick is not knowing which one you have agreed to. Below is what to check with any agency you are considering, including us.

The four things to get in writing

• Which arrangement applies to the code. Source or licence, stated in the quote. If it is source: the actual code in a repository you can access, not a compiled or obfuscated build. If it is a licence: what the licence covers, what support comes with it, and what happens if the agency stops trading.
• The hosting account. In your company's name, paid by you, with the agency added as a user. Not the other way round.
• The domain. Registered to you. This is the single most common thing to find sitting in an agency's account years later.
• Third-party accounts. Payment gateway, analytics, email sending, any API keys. Yours, in your name.

Why lock-in happens without anyone planning it

Most lock-in is not malicious. An agency spins up hosting on its own account because it is faster on day one, registers the domain with its own registrar because that is where its other clients are, and nobody writes any of it down. Two years later the client wants to move, and the handover becomes a negotiation instead of an export.

The code question goes wrong the same way, in reverse: nobody says whether the client is getting source or a licence, the client assumes source, and the disagreement surfaces on the last day instead of the first.

The fix is boring and it works: decide who owns each account, and which arrangement applies to the code, before the build starts, and put it in the written scope alongside the price and the milestones.

What "handover" should actually include

A real handover is not a zip file emailed on the last day. It should cover:

• Where the contract provides for the source: repository access, with the project's history intact.
• Where it is a licence: the installation, its documentation, and the licence and support terms in writing.
• Logins for hosting, domain and every third-party service.
• A short written description of how to deploy a change, or how to request one.
• Whatever the next person needs to work out where things are.

Does that mean the relationship ends at launch?

No — and the two are unrelated. Launch is not the hand-off point for us; we stay available for fixes, changes and the small improvements that follow real usage, either ad hoc or on a monthly arrangement. The difference is that you are staying because it is useful, not because you cannot leave.

If you are mid-project with another team and unsure what you own, the questions above are worth asking them this week. If you would rather have someone look at it with you, get in touch.