When a company pays for custom software, the most important question is often the simplest one: who owns the source code once the project ends? Software source code ownership decides whether you can change your system, move it to another team, or keep running it if the vendor disappears. The answer is set in the contract, not in the project kickoff, so the clauses need to be written clearly before any code is written.
Why source code ownership matters after launch
Source code is the set of instructions your system runs on. If you hold it, you can hire a different developer, fix a bug on your own schedule, or add a feature without asking permission. If you do not hold it, you may be limited to whatever the vendor is willing to maintain, and switching becomes expensive or impossible.
Ownership problems usually appear late. A business might discover that the repository lives in the vendor's account, that a key library was licensed in the vendor's name, or that the admin passwords were never shared. Fixing these issues after the fact costs far more than writing the right clause at the start.
The clauses your software contract should include
A good contract covers more than a single line saying the client owns everything. At minimum, check for the following:
- Intellectual property transfer: the clause should state that all custom code, designs, database schemas and documentation written for your project transfer to you on payment, or are licensed to you perpetually and irrevocably.
- Repository ownership: the Git repository should be created in your organisation's account, or transferred to it at the end of the project, with your team holding administrator rights.
- Access credentials: hosting, domain, database, cloud, email and third-party service accounts should be registered under your name or handed over with a written record of who holds which access.
- Third-party components: the contract should list open-source libraries and paid components, their licence types, and who pays for their renewals.
- Documentation: system architecture, setup steps, API references and deployment instructions should be delivered as part of the project, not as an optional extra.
- Handover process: define a date, a checklist and an acceptance step so the transfer is confirmed in writing.
- Vendor background IP: vendors often reuse internal tools or frameworks. The contract should separate what they keep from what you own, and grant you a licence to any reusable part that your system depends on.
Ownership models compared
Not every project ends with full transfer. Some vendors offer a hosted model, where they keep the code and you pay a subscription. That can be a reasonable choice for a short-term need, but it changes what you can do later. The table below shows the usual options.
| Model | Who holds the code | Who runs it | Main risk for you |
|---|---|---|---|
| Full transfer | You | You or any partner you choose | You must plan for your own maintenance or hire support |
| Perpetual licence | Vendor, with a licence to you | You, under the licence terms | Licence scope may restrict changes, resale or hosting location |
| Hosted subscription | Vendor | Vendor | Price increases, service shutdown or hard exit from your data |
Whichever model you choose, write it down in plain language. Phrases like "all rights reserved by the vendor" or "client receives a licence to use the software" need a clear explanation of what the client can and cannot do.
Common mistakes buyers make
- Signing before the repository is set up. If the code lives only on the vendor's machine during the build, insist that it moves to your account from the first sprint.
- Accepting "ownership on final payment" with no handover plan. Final payment means little if the credentials are never delivered.
- Ignoring the licences of libraries. A system built on a component with restrictive terms can limit how you sell or host it.
- Treating documentation as optional. Code without setup notes is hard for a new team to run safely.
- Forgetting the data. Your customer, product and transaction data should be exportable in a standard format at any time, regardless of who hosts the system.
How to check your current contract
If you already have a vendor relationship, you can still improve your position. Ask for a written list of repositories, server accounts and third-party services used by your system. Confirm who is listed as the account owner for each one. Then ask for the current documentation and check whether it describes how to deploy and restore the system.
If the answers are unclear, that is a signal. A reliable partner should be able to show you where everything lives and explain it without difficulty. Our ERP System and POS Subscription offerings both follow this principle: you should know what you are paying for and where your system and data sit.
Where to start with a new project
Before you request quotes, prepare a short ownership section in your requirements. List the assets you expect to receive, the accounts you need in your name, and the licence model you accept. Vendors can then price the handover work and respond to your terms directly. Our guide on writing a software requirements document vendors can price covers the wider preparation steps.
When you talk to us, we will walk through each of these clauses with you so that the contract matches the way your business will use the system. You can review examples of how we have delivered and documented past work on our projects page, or contact our team to discuss your specific project and the ownership terms you need.
Frequently asked questions
Does paying for custom software mean I automatically own the source code?
Not always. Payment alone does not guarantee ownership, because the contract decides who holds intellectual property. Some vendors keep the code and grant you a licence instead. Read the intellectual property clause before you sign.
Who should own the Git repository for my software?
The repository should sit in an account controlled by your organisation, with at least two named administrators on your side. If the vendor creates it during the build, make sure it is transferred to you at handover. Keep a record of who has access.
What happens to third-party libraries used in my system?
Open-source libraries carry their own licence terms, which the contract should list. Paid components may need renewals in your name. Ask the vendor for a full list of these items and the annual cost of keeping them active.
Can I move my software to another developer later?
Yes, if you hold the code, documentation and access credentials. A handover checklist should confirm that a new team can build, deploy and restore the system without the original vendor. Without these items, switching is much harder.
