Who Owns Your Custom Software? Source Code, IP and Handover for Australian Businesses (2026)

Most business owners assume that if they pay for custom software, they own it. It seems obvious. You commissioned it, you paid the invoice, and the thing runs your operations. Then, three years later, the developer has closed the business, or the relationship has soured, or an acquirer’s lawyers are asking for evidence of “chain of title”, and it turns out the answer is a lot less comfortable than you assumed.

Under Australian copyright law, the default position runs the other way. The person or company that writes the code is generally the first owner of the copyright in it, and that doesn’t change just because someone else paid for the work. Ownership moves to you only if a written agreement says it does. Plenty of small custom builds are done on a handshake, a short proposal or a developer’s standard terms, and those documents often say very little about it, or quietly say the developer keeps the lot.

This guide is about what you should actually expect when you commission custom software, what the contract needs to say, what “ownership” has to include in practice (the code is only one piece), and how to avoid being locked into a supplier you can’t leave. It’s not legal advice, and you should have a lawyer read any development agreement that matters to your business. But the practical side, the part that determines whether you can really walk away with your system, is something we handle from the build side, and it’s worth understanding before you sign anything.

Why “I paid for it” doesn’t settle ownership

Copyright in software arises automatically. Source code is protected as a literary work under the Copyright Act 1968, with no registration and no fee. That’s convenient for developers, but it means there’s no register you can search to see who owns what. Ownership is decided by who created the work, what their relationship was to the person who engaged them, and what any written agreement says.

Three situations come up again and again.

Employees

If someone writes code as an employee, in the course of their employment, the employer will usually own the copyright. This is the simple case, and it’s why a company with an in-house development team rarely has to think about it. The wrinkle is that it only helps you if the person really is an employee.

Contractors and agencies

If you engage an external developer or agency, the default flips. They are not your employee, so they are the first owner of what they write. You may have a licence to use the result, and a court might in some circumstances imply one, but an implied licence is a thin and uncertain thing to build a business on. It may not let you modify the software, hand it to another developer, resell it or include it in the sale of your company.

The fix is an assignment: a clause in a signed written agreement in which the developer transfers copyright in the code they write for you to you. Without that clause, “who owns it” is a question you don’t want to be answering after a dispute has already started.

Mixed teams and subcontractors

Modern builds often involve several people: an agency, a freelancer they bring in for a specialist piece, maybe an offshore contractor. Each link in that chain needs to have assigned its rights to the next. If the agency’s freelancer never signed anything, the agency can’t give you what it doesn’t have. This is the kind of gap that surfaces during investor due diligence, and it’s much cheaper to prevent than to repair.

Ownership isn’t one thing: three layers inside every custom build

When people say “we own the code”, they usually picture a single block. In reality a custom application is made of several layers with different ownership positions, and a sensible agreement treats them separately.

Layer one: the bespoke code

This is the code written specifically for your project: your business logic, your screens, your database design, your integrations. It’s the layer you should expect to own outright, via an assignment, once you’ve paid. It’s also the part that holds your competitive value, because it encodes how your business actually works.

Layer two: the agency’s pre-existing components

Most experienced developers don’t start from zero. They have reusable modules, internal libraries, starter templates and tooling built on earlier projects. They won’t assign those to you, because they use them for everyone else too, and fairly so. What they should give you is a clear, permanent licence to use them as part of your application, covering modification and maintenance, and not ending if you stop being a client.

Read this part of any agreement carefully. A licence that is “non-transferable”, “terminates on cessation of services” or “for the duration of the support agreement” means that if you leave, your application may lose parts it can’t run without.

Layer three: third-party and open source components

Almost every modern application leans heavily on open source libraries and commercial packages: the web framework, the authentication library, the payment SDK, the charting component. Neither you nor your developer can own these. They come with their own licences, some permissive and some with obligations that affect how you can distribute the software. A developer can’t assign you ownership of something they never owned.

What you can reasonably ask for is a list. A software bill of materials, even a plain one, tells you what your application depends on, under what licences, and where the risks are (an abandoned library, a licence that doesn’t suit a commercial product). This is also the first thing a technical acquirer will ask for.

What a sensible development agreement says

We’re not lawyers, and the exact wording belongs to your lawyer. But the issues a good agreement addresses are consistent, and you can check any contract you’re offered against this list.

• What is being created. A clear description of the deliverables, not just “a web application”. Ownership clauses are only as good as the definition of what they apply to.
• When ownership transfers. On creation, on payment in full, or on completion. This matters if the relationship ends mid-project. “On payment in full” is common and reasonable, but you want to know what happens to a half-built system if you part ways at month four.
• What exactly is assigned. The bespoke code, the database schema, the designs, the documentation, and any content or data you supplied.
• What is licensed rather than assigned. The pre-existing components, with the licence scope spelled out (perpetual, irrevocable, worldwide, modifiable, transferable with the business).
• Third-party and open source. A statement of what’s used and under which licences.
• Moral rights consents. Authors in Australia have moral rights, including the right to be credited and to object to derogatory treatment of their work. A development agreement normally includes consent from the individual authors so that you can modify the software freely without worrying about it.
• Subcontractors. A promise that anyone involved has assigned their rights up the chain, and a warranty that the code doesn’t infringe someone else’s rights.
• Handover. What you receive, in what form, and when (more on this below, because it’s where most real-world problems live).
• Your data. That the data in the system is yours, in a usable export format, and that you can get it out.
• What happens if the supplier fails. Insolvency, closure or abandonment of support, and whether there’s an escrow or equivalent protection.

Notice that most of this is about practical access, not abstract legal title. You can legally own something you have no ability to run.

Owning the code and being able to use it are different problems

This is the point that most ownership articles skip, and it’s where businesses actually get hurt. A company can technically own its software and still be unable to move it, because the practical keys were never handed over.

Software is not just source files. To run it, change it and recover it, you need access to the whole environment around it.

The handover pack

A proper handover has a defined list, and it should be agreed before the build starts rather than negotiated at the end when goodwill is thin.

• The source repository. The full version history, not a zip file of the latest state. The history is how a new developer understands why things are the way they are. The repository should live in an account you control, or be transferred to one, and not sit only in the agency’s own account.
• Hosting and infrastructure. The cloud account, servers, domain, DNS, SSL certificates and email sending. Best practice is that these are set up in your name from day one, with the agency given access, rather than the other way around.
• Environment configuration. Which settings and secrets the application needs, held in a password manager or secrets store you control, with the exact process for creating a new environment.
• The database and a verified backup. Not just access to the live database, but a recent backup you’ve actually proven you can restore somewhere else.
• Deployment process. How code gets from a developer’s machine to production. If the answer is “one person runs a script from their laptop”, that’s a risk you now own.
• Documentation. A readable overview of the architecture, the main data structures, the integrations and the things that break. It doesn’t have to be long. It has to be accurate and findable.
• Third-party accounts and licences. Payment gateways, mapping APIs, email providers, monitoring tools. Who is the account holder, and who gets the bill?
• A list of dependencies. The bill of materials mentioned earlier, and versions in use.

The test is simple. Imagine your developer is unreachable tomorrow. Could a different competent developer, given only what you hold, get the software running on a fresh server and ship a fix? If not, the handover isn’t done, whatever the contract says about ownership.

Credentials and the “bus factor” problem

A related risk is concentration. If one person at the agency holds the only copy of a key, a password or an understanding of how deployments work, you have a single point of failure that no clause can fix. Ask directly who else knows how the system runs, and whether any critical knowledge lives only in someone’s head.

Escrow, and when it’s worth the bother

Source code escrow is an arrangement where a neutral third party holds a copy of the source code and supporting material, to be released to you if specified events happen: the supplier becomes insolvent, stops supporting the software, or breaches the agreement in a defined way.

It’s useful in a specific scenario, and it’s frequently mis-sold outside it.

Where escrow makes sense

Escrow fits when you’re depending on software that you don’t own and can’t replicate: a vendor’s proprietary platform, a licensed product, a critical SaaS tool you’ve customised heavily. The code stays theirs, but you want continuity protection if they disappear.

Where it’s mostly unnecessary

If you commissioned bespoke software and the contract assigns the code to you, with a proper handover into your accounts, escrow adds little. You already hold the material. The better investment is making sure the handover is complete and current, because a stale deposit or an incomplete handover is the same problem under a different name.

The traps in escrow arrangements

Escrow doesn’t transfer ownership; it provides conditional access. Release triggers need to be precise. Someone has to keep the deposit up to date as the software changes, and someone has to pay for it. And unless the deposit includes build instructions and everything needed to run the software, you can be left holding a pile of code that doesn’t actually let you keep the system working. For cloud-hosted software, traditional escrow of source files often isn’t enough on its own, because the running service, its data and its infrastructure matter as much as the code.

Lock-in is usually quieter than a legal clause

Most vendor lock-in isn’t written into a contract. It builds up through ordinary technical choices, and it’s worth recognising the common forms.

• Proprietary platforms. If your system is built on a vendor’s closed low-code platform, the logic may not be exportable in any meaningful form. You own what you built in a loose sense, but it only runs on their infrastructure, at their pricing. That isn’t automatically wrong, and we cover when it’s the right choice in our piece on no-code and low-code versus custom development, but go in with open eyes.
• Unusual technology choices. A stack that only the original agency knows well makes every future developer more expensive and harder to find. Mainstream, well-documented technology is a form of insurance.
• Undocumented systems. If the only description of how it works is the code itself plus the memory of its author, switching suppliers means paying someone to reverse-engineer it first.
• Data traps. A database design that’s difficult to export, or exports that omit relationships, can trap data even when the code is yours.
• Support dependence. Contracts that bundle hosting, maintenance and development together in a way that stops you buying any one separately.

None of these is sinister in isolation. Combined, they make leaving so expensive that you stay with a supplier you’d otherwise replace, and that supplier knows it. The best defence is asking, before the build begins, “what would it take for another developer to take this over?” A good supplier answers that question happily.

Special cases worth planning for

Building an MVP or a product you might sell

If the software is, or may become, the product itself, ownership stops being a housekeeping matter and becomes a valuation issue. Investors and acquirers examine chain of title closely: who wrote each part, whether rights were properly assigned, and whether open source licences are compatible with your commercial model. Gaps found during due diligence either delay a deal or reduce the price. If you’re at the idea stage and planning a lean first release, as covered in our MVP development guide, get the assignment and contributor paperwork right from the first commit, because retrofitting signatures from people who’ve moved on is slow and sometimes impossible.

Internal tools built with AI assistance

AI-generated code adds a new layer of uncertainty. Who owns output from an AI tool, how it interacts with the licences of the code it learned from, and whether anyone on your team actually understands what it produced are all open questions, and the commercial terms of the tool you used matter. We’ve written about the practical risks in vibe coding and AI-generated internal tools. For ownership purposes the rule of thumb is: know which tools were used, read their terms, and make sure a human who can maintain the result is accountable for it.

Customising off-the-shelf software

If you’ve heavily customised a licensed product, you own your customisations only to the extent the product’s licence allows, and they typically only run inside that product. Check whether the vendor can change or discontinue the extension points you rely on. This is part of the broader build-versus-buy question we work through in custom software versus off-the-shelf.

Data, privacy and where things live

Ownership of the code says nothing about who is responsible for the personal information inside the system. If your application holds customer data, you remain accountable for it under Australian privacy law whoever built or hosts the software. The handover should therefore include clarity on where data is stored, who can access it, and how it’s deleted.

What happens when the relationship ends

Most agreements are written for the happy path. The part that matters is the exit, so it’s worth walking through what a clean one looks like.

A realistic transition

When a business moves its software from one developer to another, the new team usually starts by getting the code running in a fresh environment, then reading it, then making a small, low-risk change to prove they can ship. That first stage is where an incomplete handover shows itself. Missing environment settings, a build that only works on one machine, or an unexplained manual step in deployment all surface here, and each costs paid hours to resolve.

Planning for this from the start means those hours are small. A supplier who has been keeping the handover pack current as part of normal delivery can hand over in days. A supplier who has to assemble it from memory under pressure takes weeks, and you pay for the difference.

Notice periods and continuity

Check what the agreement says about notice for ending support, and whether the supplier must keep the system running for a defined period while you transition. Ask whether they’ll answer reasonable questions from the incoming team. These are cheap to agree at the start and nearly impossible to demand later.

Who can change the code after launch

Ownership gives you the right to modify the software, but practical modification depends on process. Is there a test environment? Is there an automated way to deploy? Are there tests that tell a new developer whether a change broke something? Software without any of these can be owned and still be risky to touch, which is part of why legacy systems end up being wrapped rather than changed, a trade-off we cover in our guide to wrapping or replacing a legacy system.

Raising this without souring the relationship

Business owners sometimes avoid the ownership conversation because it feels adversarial. It doesn’t need to be. A good supplier expects it, since it protects them as well: clear terms mean fewer disputes about what they delivered and what they’re responsible for.

Frame it as standard hygiene rather than distrust. Ask for the assignment and licence terms in writing at proposal stage. Ask what the handover pack includes and whether the quote covers producing it. Ask where the hosting and repositories will sit. The way a supplier responds is useful information. Straight answers and specific detail are a good sign. Vagueness, or reluctance to put anything in writing, tells you something you’d rather learn before the build than after.

How to check what you actually have today

If you already have custom software in place, you can audit your position in an afternoon, without a lawyer, simply to find out how exposed you are. Then you’ll know whether a legal review is warranted.

1. Find the paperwork. Locate the original proposal, contract or terms. Look for the words “assign”, “ownership”, “licence” and “intellectual property”. Note whether anything is actually signed.
2. Check the accounts. Log in to the code repository, hosting provider, domain registrar and DNS host. Whose name are they in? Can you log in without asking anyone?
3. Test the backup. Ask for a recent database backup and attempt to restore it into a test environment. A backup nobody has restored is a hope, not a backup.
4. Ask the stack question. What languages, frameworks and services is it built on? Are they mainstream and maintained?
5. Ask who else knows. Is there a second person who can deploy and fix it? Is there documentation?
6. List external accounts. Payment gateways, APIs, email services. Who pays, whose name are they in?
7. Write down the gaps. Anything you couldn’t do or find is a risk item. Fixing these early, while you still have a good relationship with the supplier, costs a fraction of fixing them in a dispute.

Many of these gaps are closed by a short, friendly conversation and an afternoon of the developer’s time. The same request after a falling out is considerably harder.

Mistakes we see most often

• Assuming payment equals ownership. It doesn’t. Without a signed assignment, the developer is presumed to own the copyright.
• Agreeing terms by email or in a proposal footnote. If ownership isn’t in a signed agreement that clearly covers it, you don’t have the certainty you think you do.
• Leaving the agency as the account holder. Hosting, domains and repositories in the supplier’s name give them practical control no matter what the contract says.
• Ignoring the pre-existing components. A narrow or terminable licence on the agency’s reusable code can leave your application dependent on a relationship you might one day want to end.
• No documentation requirement. If documentation isn’t a deliverable, it is rarely produced, and its absence becomes your cost later.
• Skipping the restore test. Backups that have never been restored fail often enough to matter.
• Letting freelancers join without paperwork. Every contributor needs to have assigned their rights, or the chain has a hole in it.
• Relying on escrow as a substitute for a real handover. A deposit nobody maintains is worse than a clear, current handover into your own accounts.
• Treating AI-generated code as free of questions. Check the tool’s terms, and keep a human who understands the output responsible for it.
• Never revisiting it. Software changes, suppliers change, people leave. A yearly check of access, backups and documentation keeps the position from decaying.

Frequently Asked Questions

Do I automatically own custom software I’ve paid a developer to build?

Not under Australian copyright law. If the developer was an independent contractor or agency, they are generally the first owner of the code they write, and ownership only passes to you if a signed written agreement assigns it. Employee-written code is the main exception, where the employer usually owns it. Check your contract, and if it’s silent, get an assignment signed.

What’s the difference between an assignment and a licence?

An assignment transfers ownership of the copyright to you. A licence gives you permission to use the software on stated terms while the owner keeps the rights. For bespoke code written for you, you should generally expect an assignment. For an agency’s reusable components, a broad, perpetual licence is the normal and reasonable arrangement.

Is source code escrow worth having for custom software?

Usually not if you own the code and have a complete handover into your own accounts, because you already hold what escrow would give you. It is more relevant when you depend on software you don’t own, such as a vendor’s platform. If you do use it, make sure the deposit is kept current and contains everything needed to actually build and run the software.

Can I move my software to a different developer?

You can if you hold the source with its history, control the hosting and accounts, have documentation and a tested backup, and the stack is mainstream enough for another developer to pick up. Whether the contract lets you is only half the question. Whether you hold the practical means to do it is the other half.

Does using open source libraries affect my ownership?

Yes, in a limited way. You can’t own open source code, and each library comes with its own licence, but using them is normal and doesn’t stop you owning the code written around them. The risks are in a licence that doesn’t suit commercial use or an abandoned library. Ask for a dependency list so you can see what you’re relying on.

Does code written with AI tools belong to me?

It depends on the tool’s terms and on how the law treats AI-assisted work, and that area is still unsettled. Read the terms of any tool used, keep a record of which tools were involved, and make sure a human developer reviews and takes responsibility for the result. For anything valuable, ask a lawyer.

Where to Start

You don’t need to renegotiate anything today. Start with the afternoon audit above: find the paperwork, check whose name the accounts are in, and test a restore. If you’re about to commission something new, raise ownership, handover and documentation at the very first conversation, because it’s easier to build those into the plan than to bolt them on afterwards.

For what it’s worth, our own approach on custom software and web application builds is that the code, the database and everything we build for you is yours outright, with no lock-in to future development with us. If you’re weighing up a build, we’re happy to walk through what a proper handover would look like for your project, with no pressure to commit to anything.

You can also see how we approach scoping on our web app development pricing page.

Worth putting this in context: because we run lean as a specialist agency rather than carrying a large account-management layer, our fixed quotes typically come in below the Australian averages covered in this guide. If you’ve already got a written quote from another agency for comparable scope, send it through and we’ll do our best to beat it.