Buying Software
Owning Your Code: Why Repository Ownership Matters
Owning your code means the repository that holds it sits in an account you control, you hold the legal right to use and change it, and you can hand it to another developer without asking anyone's permission. Anything short of that is a licence to use something that someone else holds.
The difference is invisible while the relationship is good and decisive when it is not. This post covers what ownership means in practice, what goes wrong when a vendor holds the code, and what to check in an agreement before you sign.
What does repository ownership actually mean?
It means the code lives in a GitHub or GitLab organisation that belongs to you, with you as the owner and the vendor added as a collaborator. We say on our site that you own the repository from day one, and this is what that sentence has to mean to be worth anything: the repository is created in the client's account from the start, not exported at the end.
The distinction matters because a copy handed over at the end is a copy. The history, the branches and the record of why things changed stay with whoever held the original. When the repository is yours throughout, you can see the work as it happens, and you can remove the vendor's access with one setting.
Who owns custom software code by default in Singapore?
The default is not necessarily you, which is why the agreement matters. IPOS, Singapore's intellectual property office, says on its copyright ownership page that the person who created a work owns the copyright in it, including for commissioned works, unless the creator and the commissioner agree in writing that someone else will own it. It adds that an assignment is usually done through a written contract signed by both sides.
Read plainly, paying for software does not by itself tell you who owns the copyright in it. The contract does. That page is general guidance, and how it applies to your own agreement, including software written by employees or subcontractors, is a question for your lawyer or the contract itself.
What happens when a vendor holds your code?
You become dependent on one supplier for something your business runs on, and the terms of that dependence are whatever the agreement and the vendor's goodwill allow. The problems are predictable.
- You cannot change supplier. A new developer needs the code, and the old one may supply it only on terms, for a fee, or not at all.
- Hosting becomes leverage. If the app runs on the vendor's server account, switching it off is a lever in any dispute.
- The app can vanish. If the store listing sits in the vendor's developer account, the app can be removed or lose its reviews and downloads if that relationship ends.
- The vendor may fold. A small studio can close, and its code goes with it.
None of this requires bad faith. Most vendors are not hostile. But an arrangement that only works while everybody behaves well is not a safeguard, and the time to discover that is before the project, not during a disagreement.
Which accounts should be in your name?
Every account the software depends on, registered to your business and administered by you, with the vendor invited in.
- Source code: your GitHub or GitLab organisation.
- Hosting and cloud: the account that runs the app and holds its data, billed to you.
- Domain name: registered to your business, not the vendor's.
- App stores: your Apple Developer and Google Play accounts, so the listing belongs to you. Apple's membership page notes that distributing apps requires being a member of its developer programme, so set that account up in your business's name from the start.
- Third-party services: email delivery, payment providers, analytics, maps and any other service the app calls.
The vendor can still do the work. They log in as invited users with the access they need. What you avoid is a situation where your business cannot prove it owns its own app.
What should a proper handover include?
The code is the obvious part. The rest is what makes it usable by someone who was not there.
- Credentials and secrets. API keys, database connection details and signing certificates for the app stores. These should be transferred through a secure method, never by email or chat, and rotated afterwards so the previous holder no longer has working copies.
- Environment configuration. A list of every setting the app needs to run, and where each one lives.
- Documentation. How to run it locally, how it is deployed, how the data is structured, and the decisions that look odd without context.
- Third-party licences. A list of the open-source components and paid services the code relies on, so you know what you are obliged to keep paying for or to comply with.
- A working build. Evidence that someone other than the vendor can build and deploy it from the repository.
That last item is the real test. A repository that nobody else can build is ownership in name only.
What should you check in the agreement before signing?
Read for these points, and ask for plain wording wherever they are missing or vague.
- An explicit assignment or ownership clause stating who owns the code written for you, in words rather than implication. Note any carve-out for the vendor's pre-existing tools and what licence you get to those.
- When ownership passes: on creation, on payment of each invoice, or only on final payment. Each has different consequences if the project stops halfway.
- Where the repository lives and whether it is in your organisation from the start.
- Which accounts are registered to whom, covering hosting, domains and store listings.
- The handover list: credentials, documentation and a working build, and when they are delivered.
- What happens on termination, for either side, and whether access continues while a dispute is open.
- Third-party and open-source components, and who carries responsibility for their licences.
This is a practical checklist, not legal advice. For anything that matters commercially, have a lawyer read the contract itself.
When does this matter less?
When you are buying a product, not commissioning software. If you subscribe to an off-the-shelf tool, you were never going to own its code, and the right questions are about data export and what happens if the vendor closes. A one-off website or a short experiment you can afford to lose also deserves less ceremony.
The question gains weight with the cost of replacing the software and with how much of the business runs on it. For a quotation tool your team uses every day, ask these questions before signing. For a throwaway prototype, a simple written assurance may be enough.
Our own terms are on the pricing section and they are short: you own the repository from day one, and anything past a package's scope is quoted before it is built, never billed after. Every package has a published price and a defined scope, from a S$2,800 Launch Site to a S$8,800 App MVP. Whoever you hire, ask for those terms in writing.
If a recurring administrative task is costing your business more time than it should, we offer a 20-minute workflow conversation — one task, and an honest answer about whether automation is appropriate. Get in touch.
More from the blog
AI & Automation
Is It Safe to Put Customer Data Into AI Tools?
Pasting a customer's details into an AI tool is still using personal data under the PDPA. What the PDPC's generative AI guidelines say, what to keep out, and the controls a small business can set up in an afternoon.
Security & Compliance
Bank-Detail Change Scams: The Controls That Work
"Please pay our new account" emails are a business email compromise scam that reaches firms paying subcontractors and receiving deposits. The control that stops most of it is a phone call to a number you already held.