Who owns the code and accounts after a custom build

Direct answer

Ownership is decided in the written scope or contract, not after launch, and it covers more than code. Before work starts, confirm in writing who will hold the source code, the hosting and cloud accounts, the domain, the data and the documentation, and that these will be in your name. LATYNEX hands over code, domain and accounts in the client's name; you should expect and ask for the same from any vendor.

This page is general information, not legal advice. It does not provide contract terms or wording. Have a lawyer review the agreement, particularly on intellectual property, because the correct terms depend on your jurisdiction and circumstances.

What ownership actually covers

Buyers often ask about 'the code' and forget the rest. Treat these as separate items and get a clear answer for each.

• Source code: the repository and its history, not just a compiled or deployed copy
• Hosting and cloud accounts: where the application runs and where backups live
• Domain and DNS: the name your customers use and the records that point it at your application
• Data: your users, records and files, in a form you can export
• Third-party service accounts: email sending, payments, maps, analytics and similar
• Documentation: how to run, deploy and change the system

What to have in writing

Verbal reassurance is not enough here, because the questions surface years later, often when the relationship has ended. In the written scope or contract, look for clear statements on each point below, then have a lawyer confirm the legal wording.

• Who owns the delivered code and from what point
• Which parts, if any, are pre-existing tools or libraries the vendor reuses, and on what basis you may use them
• That hosting, domain and service accounts are created in your name or transferred to it, and when
• What you receive at handover and in what form
• What happens to the vendor's access after handover
• What must be paid or completed before handover takes place

Repositories and credentials

The practical test of ownership is control. You should be able to log in to the code repository as an owner or administrator, not as a guest invited by the vendor. The same goes for the cloud console, domain registrar and any service the application depends on.

Good practice is that accounts are created under your organisation from the start, with the vendor added as a collaborator for the duration of the work. Credentials are shared through a password manager or the platform's own access controls, never by email or chat, and access is removed or reduced when the engagement ends. See web application access requirements for what a build typically needs from you.

Third-party licences that stay with their vendor

Almost every custom application uses other people's software: open-source libraries, hosted databases, payment providers, email services and so on. Owning your code does not mean owning those. They stay under their own licences and terms, and some carry ongoing fees billed by the provider.

Ask for a list of the significant third-party components and services in your build, which ones need paid accounts, and who will hold each account. Check the current terms directly with each provider, because they change. You should not be surprised later by a subscription you did not know your system depends on.

What a good handover contains

A handover is complete when someone else could run and change the system without asking the original vendor for help.

• The full source repository, with history, in an account you control
• Instructions for building, configuring and deploying the application
• A list of environments, hosting resources, domains and DNS records
• A list of every third-party service and account, with the owner named
• A description of the data model and how to export data
• Where secrets are stored, and confirmation that they have been rotated to values you control
• Notes on known limitations and open items

What happens if you change vendor

This is the real reason ownership matters. If a vendor holds the only copy of the code or the only login to your hosting, you cannot leave without their cooperation. If you hold everything, a new team can start from the repository and documentation.

Before signing, ask directly how a transition to another team would work: how quickly access can be given to someone you nominate, whether there is any fee or condition for doing so, and how long the vendor keeps any copies. The answer should be short and unremarkable. If it is complicated or hedged, treat that as a finding. For a broader comparison of what to weigh across vendors, see how to choose a software development agency.

Questions to ask any vendor

Ask each of these, and write the answers into the scope or contract review.

• Whose name will the repository, hosting account and domain be under on day one?
• What do I receive at handover, and is anything conditional on further payment?
• Which third-party services will my system depend on, and who pays and holds each account?
• Do you reuse any of your own tools or libraries in my build, and how may I use them?
• How would a new team take over, and what would you provide?
• What access will you keep after launch, and how is it recorded and removed?

Where LATYNEX fits

LATYNEX agrees one scope and one price in writing before work starts, and hands over code, domain and accounts in your name. If a particular ownership arrangement you need is not one we can offer, we will say so directly. To see how a build is scoped, read web application development, or see web application development cost for what drives price.