Hosting, Domains and Who Owns Your Source Code

Of all the questions founders ask about a new piece of software, ownership is one of the most important and most often left until it's too late. Who actually owns the domain, the hosting account and the source code once the project is finished is not a technicality; it determines whether you are genuinely in control of your own business's software, or dependent indefinitely on whoever built it.

Domains: register them yourself

Your domain name should be registered in your own name, through an account you personally control, not through a developer or agency's account on your behalf. This is a small amount of upfront admin that prevents a genuinely common and painful problem: a business relationship ending badly, and the domain effectively being held hostage because someone else's account controls it.

Hosting: know what you are actually paying for and who controls it

Hosting is where your software actually runs. Ask plainly, before work begins, whether the hosting account will be in your name or the developer's, what it costs on an ongoing basis, and what would happen if you wanted to move to a different provider or a different developer later. There is no single right answer for every business, but there is a right answer for you, and it's worth knowing it in advance rather than discovering it during a dispute.

Source code: who owns what gets built

In the UK, unless a contract says otherwise, the default legal position on who owns copyright in custom-written software is not always what people assume, and it varies depending on the exact commercial relationship. This is exactly why it should be an explicit, written term of any agreement with a software company, and one of the questions worth asking before you appoint anyone, not an assumption on either side. A reasonable, common arrangement is that once you have paid for the work, you own the code that was built specifically for you.

• Ask directly: once this is built and paid for, do I own the code outright?
• Ask whether the answer is written into the contract, not just said verbally.
• Ask for a copy of the actual source code and understand where it lives (a code repository you also have access to is a reasonable, common expectation).
• Understand the difference between code written specifically for you, and any general-purpose tools, frameworks or components the developer reuses across projects, which they may reasonably retain rights to.

Why this matters beyond the legal technicality

Ownership is really about control: whether you can change developers, hire someone else to make a change, or bring the work in-house later, without being blocked by someone else holding the keys. It has nothing to do with distrust of any particular company; it's simply good practice, in the same way you would not want a single supplier to be the only entity capable of unlocking your own shop.

At Appiloom, this is something we set out plainly at the start of every engagement, precisely because we think a client should never be dependent on us continuing to be the only people who can touch their own software. If you’re starting a project and want to understand exactly how ownership would work before committing to anything, that’s a perfectly reasonable question to ask upfront.