Owning the Code: What to Ask Before You Sign a Custom Software Contract

Most custom software contracts are negotiated around price, timeline and scope. Ownership gets a single clause near the end, often copied from a template, and nobody reads it closely until the relationship ends. That is the moment it matters most. If you cannot take the code, the infrastructure and the knowledge with you, you did not really buy software. You rented a team that holds the keys.

This guide sets out the questions we think enterprise buyers in Singapore should ask before signing. It is practical guidance from the build side of the table, not legal advice, so put your final draft in front of your own counsel. What it will do is make sure the conversation with your lawyer covers the right ground.

Start With Who Owns the Intellectual Property

Do not assume that paying for code means owning it. In many jurisdictions, including Singapore, the starting position for work produced by an outside contractor is not automatic client ownership. The contract has to say clearly that the intellectual property in the deliverables is assigned to you, when that assignment happens, and whether it depends on final payment.

• Is the IP in all custom deliverables assigned to us outright, or only licensed to us?

• Does the assignment cover source code, designs, data models, test suites and documentation, or just the compiled application?

• Does ownership transfer on each milestone payment, or only when the whole project is paid off?

Milestone based assignment is worth asking for. If a project stops halfway, you want to own the half that was built and paid for.

Separate Bespoke Work From Background IP

Every serious vendor brings existing tools, libraries and frameworks to a project. That is a good thing, because it is why they can deliver faster. It does mean the contract needs a clear line between background IP, which the vendor keeps, and foreground IP, which is built for you.

Ask for a written list of any background components that will be in your codebase, and a perpetual, royalty free licence to keep using them in your product after the engagement ends. Without that licence, a vendor can technically own a piece of the system you depend on. Ask the same question about open source: you want a list of third party packages and their licences, so your own team can check nothing conflicts with how you plan to distribute or commercialise the product.

Owning the code is only useful if you also own everything the code needs to run.

Repositories, Accounts and Access From Day One

The cleanest way to avoid a handover fight is to never need a handover. Ask for the source code to live in a repository your organisation owns from the first commit, with the vendor invited as collaborators. The same applies to cloud accounts, domain names, app store listings, analytics properties and any third party services the product depends on.

• Will the code be committed to a repository we own and control, with our administrators holding the top level permissions?

• Will cloud infrastructure be provisioned in our accounts, billed to us, and defined as code so it can be recreated?

• Who holds the credentials for production systems, and how are they rotated when people leave the project?

If a vendor insists on hosting everything in their own accounts, ask why, and ask for a written plan and timeline for moving it across.

Documentation That Another Team Could Use

Documentation is the part of a project that is easiest to cut when deadlines tighten. Make it a deliverable with acceptance criteria. A reasonable standard is that a competent engineering team who has never seen the system could set it up, run it, deploy it and make a small change, using only what is in the repository.

In practice that means a setup guide, an architecture overview, a record of the key technical decisions and why they were made, runbooks for common operational tasks, and an up to date description of every integration with your other systems. Ask to review a sample early in the project, so you are not discovering gaps in the final week.

Plan the Handover Before the Kickoff

Whether the vendor stays on for years or hands over to your internal team after launch, the exit should be planned at the start. A good contract describes what a handover includes, how long it lasts and what it costs.

• How many hours of knowledge transfer, pairing or shadowing are included when we take the system in house or move to another partner?

• Will the vendor support a transition period at agreed rates, and for how long?

• What happens to our data, backups and logs held by the vendor once the contract ends, and how will deletion be confirmed?

When Source Code Escrow Makes Sense

Escrow is a safeguard for cases where the vendor keeps some of the IP, for example when your product sits on top of their licensed platform. A neutral third party holds a current copy of the source code and documentation, and releases it to you if specific events happen, such as the vendor ceasing to trade or failing to meet support obligations.

If you own the repository outright, escrow adds little. If you do not, it is worth considering, and the details matter. Agree how often deposits are updated, whether the escrow agent verifies that the deposit actually builds, and exactly which events trigger a release. An escrow deposit that is two years out of date and does not compile is not much protection.

Questions About People and Continuity

Code is only part of what you are buying. The other part is the understanding of your business that the delivery team builds up over months. Ask who the named leads are, how the vendor handles changes in key staff, and how decisions and context are written down so they do not live in one person's head. For long engagements, ask how the vendor would support you hiring some of that capability internally over time.

A Short Checklist for the Final Draft

• IP in custom work is assigned to us, on payment of each milestone, with background IP licensed perpetually.

• Code, infrastructure and accounts live in our organisation from the start, with a documented list of dependencies.

• Documentation and handover are deliverables with acceptance criteria, and escrow is in place where we do not own everything.

Our engagements are set up this way by default, because clients who own their software tend to trust their partners more. If you are scoping a build and want a second view on the contract terms, talk to us. You can also read how we approach custom software delivery or browse our work.