Who Owns the Code When You Hire a Software Developer

Why This Question Catches Business Owners Out

Most business owners paying for custom software development assume that once the final invoice is settled, the code belongs to them outright. That assumption is often wrong, and the gap between what a business expects and what the contract actually says only becomes visible once it stops being hypothetical — usually right when a business needs to switch developer, extend the software in-house, or bring on a new team.

Code ownership is not automatic just because you paid for the work. Ownership only transfers if the contract explicitly says so — otherwise the developer or agency retains the underlying rights and only licenses you to use the software, even after final payment.

The confusion isn't really about custom software as a concept — it's about contracts that never explicitly address ownership at all. A statement of work that describes what gets built, the timeline, and the price, but says nothing about intellectual property rights, defaults to whatever general commercial law implies, and that default frequently favours the developer, not the business that paid for the work.

This matters more for custom software than almost any other purchase a business makes, because the software is often core to how the business operates — a booking system, an internal tool, a customer portal. A business that doesn't control that code doesn't fully control its own operations.

What Ownership Actually Means In A Contract

There are two very different outcomes a development contract can produce, and the wording that separates them is easy to miss. The first is assignment — full intellectual property rights, the legal rights that protect original creative and technical work, transfer to the business on completion or final payment, and the developer keeps no ongoing claim over the code. The second is a licence — the developer retains ownership and grants the business permission to use the software, usually indefinitely, but the underlying rights never move.

A licence isn't automatically a bad outcome for every purchase — off-the-shelf software is licensed, not assigned, and that's expected because thousands of other customers are using the identical product. Custom development is different. A business commissioning bespoke, purpose-built software has paid specifically for something no one else has, and a licence arrangement means the developer, not the business, decides what happens to it long term.

The practical effect shows up later, not at the point of signing. A business operating under a licence can keep using the software as it currently stands, but modifying it, extending it with a different developer, or moving it to different infrastructure can require permission that was never guaranteed in writing.

The Frameworks And Components Some Agencies Hold Back

Even contracts that do assign ownership sometimes carve out exceptions for the underlying frameworks, libraries, or starter code the agency built the project on top of. An agency that reuses its own proprietary toolkit across multiple clients has a commercial reason to keep that toolkit its own property, licensing it to the client rather than transferring it outright.

This isn't necessarily dishonest — reusing proven components is normal, efficient practice, and it reduces build time and cost. The problem is when an agency leaves the split between what transfers and what stays with them vague, or buries it in a way that only becomes clear if a business later tries to move the code elsewhere and discovers a licensed dependency it can't take with it.

The fix isn't refusing to work with any agency that reuses code — nearly all custom development does, to some extent. The fix is a contract that names exactly what transfers and what doesn't, so a business knows in advance rather than finding out at the worst possible moment.

What To Check Before You Sign

A handful of specific questions separate a clear ownership position from an ambiguous one, and they're worth asking directly before signing rather than assuming the answer.

• Does the contract state that intellectual property rights transfer on final payment, in those or equivalent words
• Does it name any frameworks, libraries, or components excluded from that transfer, and are they clearly licensed rather than assigned
• Does the business receive the full source code, not just a running application
• Can the business take the code to a different developer without needing further permission from the original agency
• Are login credentials, hosting access, and any third-party accounts handed over in full

If a contract is silent on any of these points, that silence is the answer, not a gap to assume in the business's favour.

Why It Matters When The Relationship Ends

Ownership questions rarely matter while everything is working. They matter when a business wants to move fast on a new feature and the original developer is unavailable, when the relationship breaks down, or when a business is simply ready to bring development in-house or switch agencies.

A business that doesn't own its code, or doesn't have clear rights to it, effectively can't leave. Even with the willingness and budget to appoint someone else, a new developer can't take over software they have no legal right to modify, and a licence that never specified transfer terms leaves that decision entirely with the original agency.

This is why ownership belongs in the contract before work starts, not something to negotiate after the relationship has already turned difficult. The moment it becomes worth raising is usually the moment it's too late to raise cheaply.

Softy's Approach To Code Ownership

Full intellectual property ownership transfers to the client on completion, with no exceptions carved out for frameworks, components, or anything else built during the engagement. That position is written into the contract, not implied or left for a client to assume.

This matters most for businesses that have outgrown off-the-shelf tools and are commissioning something genuinely bespoke — the whole point of custom software is that it belongs to the business that commissioned it, built around how that business actually operates, with no dependency on the original developer remaining in place forever.

A business considering custom software development should be able to ask directly who owns the finished code and get a straight answer before any work begins.