Ask Your Dev Team who owns the code
Your developer writes the code, but who actually owns it? Learn about IP ownership, licensing, work-for-hire, and how to protect your investment.
Your developer writes the code, but that doesn’t automatically mean you own it. Intellectual property ownership is one of the most important and most overlooked parts of a software development contract.
When does ownership transfer?
The best contracts are clear about when IP transfers to you. There are good structures and bad ones.
Good: Ownership transfers on a milestone or time-based schedule. For example, all work completed in February becomes yours when the February invoice is paid. This is clean, predictable, and fair to both sides.
Bad: Ownership doesn’t transfer until all payments across the entire engagement are made. That means if you’re six months into a twelve-month project and you’ve paid every invoice on time, you still don’t own any of the code. That’s a bad deal for you.
Look for contracts that tie ownership to paid deliverables, not to the completion of the entire engagement.
Two types of deliverables
Not everything your developer builds is the same, and the ownership rules can differ.
Type A: Custom work
This is code written specifically for you, your features, your business logic, your application. In most cases, this should be your IP once it’s paid for.
Type B: Pre-existing or reusable work
Developers often have libraries, frameworks, or tools they’ve built before your project that they incorporate into your work. Think of it like a contractor who brings their own specialized equipment to a job site. They’re not giving you the equipment, they’re using it to build your house.
Some developers retain licensing rights to Type B deliverables until all invoices are paid. That’s not unusual, but you should know about it upfront. Once you’re paid in full, look for universal, irrevocable licensing terms that let you use, modify, and build on everything they’ve delivered without restrictions.
Work-for-hire language
Always look for work-for-hire language in your contract. Work-for-hire means the work product is legally yours from the moment it’s created. Without it, the developer may retain certain rights even after you’ve paid.
This is especially important for Type A deliverables. If custom code is built for your business, you should own it outright. Work-for-hire language makes that unambiguous.
Open source and licensing
Most modern software uses open source libraries. That’s normal and usually fine. But it’s worth asking your developer about copyleft licenses, which can require that any software using them also be made open source.
In practice, this is rarely an issue. Most developers know which licenses are safe for commercial use. But it’s a good question to have answered, especially if your software is proprietary.
Source code access
Ownership on paper doesn’t help you if you can’t access the code. Make sure your contract includes provisions for:
- Repository access: You should have the option to access the code repository directly, or at minimum, receive source code deliveries as ownership transfers
- Delivery cadence: When an invoice is paid and ownership transfers, the corresponding code should be delivered to your own repository or environment
- Deployment access: You should have access to, or shared access to, the environments where your software runs
If your developer pushes back on giving you access to the code you own, that’s a red flag. You wouldn’t buy a house and let the builder keep the only key.
Expect better. Build better.