Source Code, Domain and Accounts: What Must Stay Yours When You Commission Software

There's a scenario that happens more often than you'd think. A business commissions a website, an app or a management system. The project works, a couple of years go by, then the relationship with the developer ends: they change jobs, stop replying, or the business simply decides to move on.

That's when it turns out the domain is registered in the developer's name. That the app is published on their developer account. That the server is paid for with their card and the code lives on a computer nobody else can access.

Nobody had bad intentions. At the start, it was simply more convenient that way. This article is here to stop that convenience from turning into a problem.

This is what surprises first-time buyers the most: having paid for development doesn't automatically make you the owner.

In Italy, as in many other countries, software is protected by copyright, and the rights belong to whoever writes it in the first place. Automatic transfer to the business applies to employees; when software is commissioned from an external supplier, what counts is what the contract says. If the contract is silent, the real risk is ending up with a simple licence to use rather than ownership.

I'm not a lawyer, and it's always worth having a legal professional look at the contract. But the question to ask is simple: does the contract assign the rights to the software, or only grant a licence to use it? Either answer can be fine, as long as it's clear before you sign.

The domain. Registered to your company, with the registrar login in your hands. The domain is the address customers find you at and the one your email runs on: losing control of it is the most immediate damage.

The source code. In a repository (GitHub, GitLab or similar) owned by the company, or that the company has full access to. And delivered continuously, with every release, not in a single package at the end of the project.

Hosting and cloud services. Servers, databases, backups: accounts in the company's name and paid for by the company, with the developer invited as a collaborator. If the developer disappears, the services keep running and someone else can take over.

App store accounts. If you have an app, it should be published on Apple Developer and Google Play Console accounts registered to your company. Transferring an app from one account to another is possible, but it's a procedure you'd rather not have to face.

Credentials for connected services. Payments, transactional email, notifications, maps, API keys: every service the software uses should be set up with a company account. Especially the ones money flows through.

It's worth being balanced here, because not everything has to pass to the client.

An experienced developer uses components, libraries and tools they've built over time and reuse across projects. It's normal — and it's one of the reasons they work faster — for those parts to remain theirs, with a licence to use them in your project. The same goes for open-source frameworks, which come with their own licences.

What matters is that the part specific to your project is yours, and that the reused parts don't stop you from continuing to use, change or have someone else maintain the software.

Five questions, asked directly. A serious developer answers without hesitation.

Whose name will the domain be in? The right answer is: yours.

Where will the code live, and will I have access? In a repository you can access, always.

Does the contract assign the rights or grant a licence? Either can be fine, as long as it's in writing.

What happens if we stop working together? There should be a concrete answer: what gets handed over, and how quickly.

Could another developer take over? That takes minimal documentation: how to install the project, how to deploy it, where the services are.

You might think keeping clients locked in is in the developer's interest. In the short term, perhaps. But a client who stays because they can't leave isn't a satisfied client: they're a hostage, and sooner or later they realise it.

The healthy relationship is one where the client could leave at any moment, and chooses to stay because the work is good. It's a higher bar, and it's the right one.