ERY SOFTWARE6 min read
Many businesses discover what they do not own only when they want to change agency, move hosting or hire their own developer. The domain is registered in someone else's name, the code lives in an account they cannot access, and nobody remembers the password to the email service. All of this is avoidable with a few clear agreements at the start.
1. The domain name
Your domain is your address on the internet. It should be registered in your company's name, in an account you control, with a contact email you read. A developer can be given access to manage DNS settings, but ownership should stay with you. Check the renewal date and turn on auto-renewal.
2. Hosting and infrastructure accounts
Hosting, databases, file storage and email services each have their own account. Decide early who holds each one and who pays for it. Either model can work — you hold the accounts and give access, or the team manages them for you — as long as it is written down and you can take over without asking for favours.
3. Source code
Source code is the actual product. Ask how and when it will be delivered, in which repository, and what rights you have to use and change it. Our default approach is that what we build for you belongs to you; the exact terms are set per project in the contract. Whatever the agreement, make sure it is explicit.
Be aware that a project often includes parts that cannot be transferred: open-source libraries with their own licences, paid themes or plugins, fonts and stock images. That is normal; what matters is that these parts and their licences are listed.
4. Third-party services
Payment providers, maps, email delivery, analytics and messaging services are usually tied to an account and often to a card. Accounts that bill your business should be in your business's name. Keep a simple list: service, purpose, account owner, monthly cost, renewal date.
5. Content and data
Texts, images, product data, customer records and form submissions are yours. You should be able to export them in a usable format. Ask how backups are made and how you would get a full copy if you needed one.
6. Documentation and handover
Good handover documentation answers simple questions: how is the project run locally, how is it deployed, where are the environment settings kept, which services does it depend on, and what are the known limitations? With this, another developer can continue the work. Without it, even good code becomes expensive to maintain.
A short checklist
- Domain registered to your company, in an account you control
- A written list of every account, its owner and who pays
- Clear contract terms on source code delivery and usage rights
- A list of third-party components and their licences
- A way to export your content and data
- Handover documentation and admin access for your team
None of this is about distrust. Clear ownership makes the relationship with any development team calmer, because both sides know exactly where responsibilities begin and end.
Have a project in mind?
Send us a brief